You actually have that hot keyed don't you Alex!!!
Your sig only appears when you post that!
For anyone else reading this, here is the link Alex references: http://blogs.adobe.com/aharui/2007/03/modules.html
Thanks Alex. So, you comment in your presentation that you cannot refer to classes in a module, only their interfaces. I presume this is somewhere around the heart of the issue. Let me expound so that I am clear.
1. I have my custom class(es) in a .swc library that is referenced in the project that I build the module in. Thus, I would expect the class to be loaded in the module when it is compiled. The code where the error occurs is in the module.
2. So, I noted I had not included the .swc in my parent application (separate project from the module) source. Thought maybe that was the issue. Did that and compiled and still got the error.
3. Then I added a reference to the offending class in the parent application: private var myClass:MyCustomType and the error went away. So, clearly the app did not register the class. But it seems that should not matter if the code is in the module which should have included the class there.
Progress, in one sense, but a complete regression in another. If I have to reference each custom class that is used in my module expicitly in my parent app to get it to work, something seems wrong. Further, all the offending code is in the module.
You mention RSLs, but I am not sure that is the answer since my library is a .swc and the idea of referencing all the classes in my library defeats the purpose of modules and optimization.
How do I get around this? Seems a significant inefficiency I am up against, not to mention pain in the arse. Thoughts?
1 person found this helpful
The key point is that modules load into a child applicationDomain by default
so the parent app cannot see the child's classes. Putting the classes in
the main app is sort of a solution, but defeats the encapsulation of putting
the classes in the module as those classes are now baked into the main app,
making it bigger.
The recommended practice depends on the goal. If the goal is to have a main
app communicate with the modules, then a shared interface is recommended.
The interface is lightweight and goes in the main app and both the main app
and module can use it. The interface defines the abstraction that you are
probably trying to achieve.
If the module is using a singleton to be shared with other modules then the
class must go in the main app or you can use the "shared code module"
technique or RSLs.
In my current case, the main application is not communicating with the module at all. Just loading it.
However, I am using Mate and the problem I am having is in an event map in the module. My suspicion is that somehow, the event map in the module is functioning as if it is in the parent application, which does not have the class definitions. Not sure how that would happen, but will pursue it in the Mate forum.
Thanks for the clarifications.