ModuleLoader is a kind of strange API that is really just intended to
look like SwfLoader for modules that contain a single visual component,
and hides most of the module loading infrastructure, which is all about
class factories.
What I mean by "only loaded once" is that if you have several places in
the code that call the ModuleManager.getModule("url").load() call, it
will only ever get loaded over the wire and interpreted once, subsequent
"loads" will just re-dispatch pseudo-load events to the new client. In
other words, the class factory is a singleton for a given url.
Unloading is a totally different story. As you note, not everything is
truly unloadable, because there may be lots of references to stuff in
the module that will keep it alive and un-GC'ed.
I suggest playing with the low-level API so that you understand the
backing implementation, and this should help you understand the limits
of ModuleLoader.
-rg
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of Fabio Terracini
Sent: Thursday, January 11, 2007 1:43 PM
To: [email protected]
Subject: Re: [flexcoders] Re: Compiling modules
Hello Roger, you told below that they only ever get loaded once.
This "loaded" mean loaded in memory or loaded by transferring over the
wire?
I've made tests between Modules and SWFLoader, specifically
about memory consumption. In one of them, I called loadModule() and
unloadModule() several times (loading the same module, of course), and
the memory only increases! I think this is the expected (although not
the willed) behavior (as is in the SWFLoader) since Flash Player can't
really kill (and free the memory) a DisplayObject. It would be a hard
work to remove all the references of the loaded application's objects
(without talking about the Flex framework per se) to elect they to GC.
Thanks
Fabio Terracini
On 1/9/07, Roger Gonzalez <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > wrote:
The main difference between modules and applications is
that modules have lower overhead, and they only ever get loaded once, no
matter how many times you load them.
If you're using the ModuleLoader API, keep in mind that
you're losing about half the functionality of the module system. I will
assume that you are, because otherwise it would be obvious where to
expose methods. You might want to play around with the lower level
ModuleManager API just to get a hang of what's going on - ModuleLoader
is a pretty thin veneer over the lower API.
Basically, what you want to do is to have your module
implement an interface, say IModuleWhatever.
Have your application implement another interface, say
IShellWhatever.
Now, add an event handler in the shell application such
that when the module is loaded, you get called back.
The ModuleLoader's "child" property will be an instance
of your module class. You can cast it to the interface inside the shell
application, and then do something like:
IModuleWhatever(moduleLoader.child).setupStuff(IShellWhatever(app))
-rg
________________________________
From: [email protected]
<mailto:[email protected]> [mailto:[email protected]
<mailto:[email protected]> ] On Behalf Of Brian Holmes
Sent: Tuesday, January 09, 2007 8:05 AM
To: [email protected]
<mailto:[email protected]>
Subject: RE: [flexcoders] Re: Compiling modules
Roger,
Would it be possible to get an example of how a
shell app could communicate or pass data to a module and vice versa. I'm
having difficulty understanding of how to expose methods on both sides
that allow for interoperability. What I'd like to do is to load user
data in the shell application and then add modules at runtime as needed.
If they require user information then have them look to the shell for
that information so it's always in the same place.
And Also, I can't really see any real difference
between a module and another application except for it's extremely
tedious to debug the modules?! Couldn't the module automatically look
for a debug version of the swf if the shell is a debug version?
Thanks,
Brian
________________________________
From: [email protected]
[mailto:[email protected] <http://yahoogroups.com> ] On Behalf
Of Roger Gonzalez
Sent: Monday, January 08, 2007 2:35 PM
To: [email protected]
Subject: RE: [flexcoders] Re: Compiling modules
I can't think of any reason why you would want
to do this.
Modules are class factories, not instances.
You will create an instance of the class baked
into the module, and then the application can pass those parameters to
the instance.
-rg
________________________________
From: [email protected]
[mailto:[email protected] <http://yahoogroups.com> ] On Behalf
Of John Kirby
Sent: Monday, January 08, 2007 12:32 PM
To: [email protected]
Subject: Re: [flexcoders] Re: Compiling
modules
Thanks for the examples.
Question... if you are passing
parameters to a module I assume your url syntax is the same as a
SWFLoader (myswf.swf?foo=bar) ... but module has no parameter property?
How do access passed parameters to a module?
phillips1021 said the following:
See:
http://www.brucephillips.name/blog/index.cfm/2007/1/8/Example-Of-Using-M
odules-In-Flex-201
<http://www.brucephillips.name/blog/index.cfm/2007/1/8/Example-Of-Using-
Modules-In-Flex-201>
for a simple example.
--
Whether you think that you can, or that
you can't, you are usually right.
- Henry Ford
________________________________
***
The information in this e-mail is confidential
and intended solely for the individual or entity to whom it is
addressed. If you have received this e-mail in error please notify the
sender by return e-mail delete this e-mail and refrain from any
disclosure or action based on the information.
***
