I have seen ur article and ur comment on using ModuleLocator in Cairngorm Framework … and it is really fantastic.

Actually I’m too working on the same approach for my application development. But I have been struck with a problem that is, not able to load the Module in a ModuleLoader through this approach.

In my application I have the following files:

1) CheckLogin.mxml – Main Application Mxml contains the Services, Front Controller and a script (AppStarter)

2) AppStarter.as – It is the actionscript which extends the container to create the ModuleLoader to load the default LoginModule

3) LoginEvent.as – It is for defining the loginevent generated by the Login Button.

4) LoginCommand.as – It is for the executing after the event had fired, here I have called the Appstarter to load the Thanksmodule in the ModularLoader.

My application loads the Default Module (Login Module) properly and on submitting the event it fires properly and dispatches it to the Login Command, the Command also executes the method in the AppStarter for loading the Module in the ModuleLoader, here in this area I didn’t find any response at all. It doesn’t load the New Module I have specified to load in the Loader.

Check out Cliff Hall’s PureMVC (http://puremvc.org/). It’s cleaner and lighter then Cairngorm. PureMVC solves many of the Cairngorm singleton problems.

So, you can still bind to the ModelLocator, but not actually have the ModelLocator compiled into the Module.swf.

The tricky thing here, however, is the Event classes. Assuming your application has trust with the module, you have a few options.

First, you could simply just use Modules for their GUI portions, meaning, the GUI code & controls that make it up are what is being ‘loaded later’, and thus taking advantage of modules in that it’s not loaded up front. Your Event classes to trigger Cairngorm Commands could be in the same externalized file, meaning the main application compiles the class in, and the Module will just use that one when it loads in.

Second, you could only embed the Use cases (Events + Command classes) in the module. When it loads, it’ll have to register it’s Event’s with Commands to run in the Controller. While this is nice in that further classes are abstracted to the module, you have a danger of a module ‘leaving it’s mess’ when it leaves. This means, Garbage Collection may not collect everything, or even the module since some classes that reference it may still exist. This is dangerous, but if you watch your self, you can take most advantage of what Modules have to offer.

Third option is to go with the contract concept (interfaces), and extend the main ones they give you with talking to modules. You basically write an interface that ‘knows’ about Cairngorm stuff, and the Module has the same thing. When the Module is loaded, it tells the shell application the Events & Commands it would like to register. When the Module is unloaded, this contract ensures that the Module ‘checks out’. Remember the Blue’s Brothers, when Jake leaves prison and get’s his personal possessions on the way out, each being checked on a form all formal? It’s the same process with modules. If they are ‘Cairngorm Modules’, they will have the same interface the shell has, and both can ‘check in classes’ and ‘check out classes’ to ensure the Garbage Collector can do his job. When you get here, check your coat at the door. When you leave, don’t forget your coat.

Fourth option is do #3, but have Modules know nothing about Cairngorm. Instead, they just emit events, similar to how a Button emits a click event. The Module loader, or whatever class is loading in the modules, is responsible for running Cairngorm events via the CairngormEventDispatcher. That way, Modules have nothing to do with Cairngorm. This is kind of hard, though, because as your Modules increase in scope, you’ll start to want a framework. Fine line.

Fifth option is to use #4, but allow ModelLocator to be used by the Module for data-binding purposes. An OOP purist would stick to #4, though.

Me? I’d use #3 and #4. Convention & contracts rock the mic.

I’m sure its in the works, but neither framework has really talked about best practices with the new mx:Modules. For example, does each module have its own model locator, its own services? How should the front controller learn about the module’s events/commands and register them. Any ideas or advice?