"Fully" Encapsulated Dynamic Modules

[riafan]

Okay we’ll as close to ‘fully’ as one can hope for :-)

I’m fine with the modules dispatching events and the shell app picking those events up.  Likewise I have no problem implementing the modules to a common interface to facilitate shell->module communications.

I’m hoping to achieve the following…

1) Modules [swfs] dynamically loaded /unloaded during runtime. 
2) My ‘shell’ app won’t know what modules will be loaded at compile time. (Read in from config / rpc / IoC scheme / etc @ runtime).
3) Each modules ‘mediator’ code will reside w/in the module NOT the main app.

Any tips on doing this (i.e. #3)?

[puremvc]

You need a Proxy that is responsible for reading a configuration file from a predetermined location. That file can contain info that tells it where to get modules.

You need another actor that is responsible for managing the modules. Much as the Model keeps a map of Proxies, this actor keeps a map of modules. This actor also needs to be able to take configuration from the other actor and use it to create factories for modules, create (or defer) loading of each module, as well as creating or deferring some configured number of instances of each module once loaded. It should keep the factory on hand to lazy load configured modules.

In the Modularity demo, the modules create objects, attach mediators to them and then 'inject' them into the parent application via the shell interface. That demo sidesteps a lot of issues because it is just a proof of concept to show multiple cores interacting. It doesn't deal with loading and unloading.

Having the Mediator for the module itself living inside the module itself, it doesn't make that much sense though. If the module is to talk to the surrounding app in a loosely coupled way, it  may only send events to make its wishes known to the main app. The main app would have a Mediator for the module, and it would hear, for instance, an unload request, and communicate with the rest of the app to unhook the module from the surrounding apparatus. A mediator inside the module itself would have no connection to any of that, and would not be trusted to comingle notifications with the main app.

-=Cliff>

[riafan]

Thanks for the reply!!

I glad to say I've got it working
With a few changes to my original 'brain storm.'  Here's what I ended up with...

My modules communicate w/each other and the parent app.  Likewise the parent app communicates w/each module.  The parent app has NO IDEA what modules will be loaded or how many.  The modules are loaded / unloaded dynamically at runtime.  This provides me with the scalability I was shooting for - my parent app doesn't have to be re-compiled for every 'nth module I write.

I'm staying fairly well encapsulated as well - my modules don't reference the parent app, it's facade or anything like that. 

[zilet]

So as I can understand here.

 MainApp --> module interaction is done through ModuleMediator which holds the reference to the actual instantiated module. Module mediator listens to the notifications from the rest of the app?

 module --> MainApp interaction is done through event listener in ModuleMediator ?

 And how are you supporting multiple modules loaded at the same time and communication between them (if you needed this).


 

[riafan]

Okay,
 I've posted a working demo at http://dluminosity.com/blog/2008/05/19/dynamic-flex-modules-with-puremvc/. 

The application->module, module->application 'bridge' resides in a function added to the module's facade...

:

   
 override public function initializeMappings():void
{
    outboundMappings:Array = new Array();
    outboundMappings[QUOTE_GENERATED] = EventNames.LOAN_QUOTE_READY;

    inboundMappings = new Array();
    inboundMappings[EventNames.REQUEST_FOR_LOAN] = QUOTE_REQUESTED;
}

The module will 'subscribe' to any notifications in 'inboundMappings.'

[puremvc]

Nice demo, Joshua.

I'm sure others will be glad to check out the code when you have it ready to post.

-=Cliff>

[riafan]

Thanks,
  I've posted a [quick] AS3 demo as well http://dluminosity.com/blog/2008/05/24/as3-puremvc-dynamic-modules/ for those interested.

[c64]

Hi, guys!
I'm working on my modular application based on Flex/PureMVC Multicore, and experience problems with unloading modules (each of them written with Multicore). It seems that module couldn't be fully unloaded and then garbage collected with Flex GC. May be PureMVC objects keep references to the module from where they were created? Can this be a reason? How can I solve this?
Sorry for my English ) Thank you.

[c64]

Mmm... seems facade.removeCore() can be helpful. Should dig in!

[puremvc]

Yes, removeCore should do it. Of course there could be complications when UI components are shared between modules.

For instance, in Modularity the modules generate buttons to be placed in the main app's canvas for display.

So the app not only has a reference to the module itslef that must be nulled before that module can be unloaded, but it might also have a reference to one of the buttons created (and mediated) by the module.

The point is removeCore will remove the MVCF core for the key you give it, and all the framework references to things will go away.

But if a mediator inside a module has a ref to a view component its sharing with the shell or some other core, then you need to remove that mediator, and in its onRemove, make it null the reference to that view component. Now the module is divested of it and can be GC'd. But you also need to be sure the main app gets rid of the now orphaned and useless UI component that the module was mediating.

-=Cliff>