This is partially true. If the module is essentially a graphical component and is loaded manually (sans module loader) and is cast to a DisplayObject using createFactory (ModuleInfo). and then added. behavior is much more agreeable. The caveat is that this approach obviates the need for an Interface. If you are coding against interfaces you avoid inter-module communication woes. With some finesse you can load either visual modules or module libraries. and unload them when they are no longer needed.
Cheers, Rick Winscot From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Alex Harui Sent: Tuesday, March 04, 2008 1:10 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Stupid question regarding Alex Harui's Modules PPT A module loaded into the main application domain cannot be unloaded. _____ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of aduston1976 Sent: Tuesday, March 04, 2008 7:17 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Stupid question regarding Alex Harui's Modules PPT In Alex Harui's Modules powerpoint (http://blogs.adobe.com/aharui/360Flex2007/Modules.ppt/Modules.ppt) he explains the problem that can result when classes are defined in a module and then accessed from another module. In Slide 20 he shows one solution for shared code between modules: load the common code into ApplicationDomain.currentDomain before loading the modules that use the common code. My stupid question: Why not just load all modules into ApplicationDomain.currentDomain? In many scenarios, this could eliminate problems with class definitions being defined in certain modules and being invisible in others. Maybe Alex's blog is a better place to ask this question, I'm not sure. Thank you, Adam
<<image001.jpg>>
<<image002.jpg>>
