I don't think this is a bug (actually nothing work wrong) but org.puremvc.patterns.observer.Notifier should not have to implement org.puremvc.interfaces.INotifier?

Hi folks,

We are facing some problems in working with PureMVC and Flex Modules.

Many approaches have been tried but without success.

What we need it’s that all modules work in an independent manner, I mean all modules will be developed using PureMVC but when they be loaded into the main application (using or not PureMVC) their behaviors cannot interfere on each other. In this case constants name, mediators name, proxies name, notifications sent, etc. might not crash with any other module (nor even go outside the module, in case of notifications).

One approach that seems to be the one we are looking for it’s to keep each module in different ApplicationDomain when loading them, but it did not work very well and an error “SWF is not a loadable module” was got every time we tried. We also have the disadvantage of increasing modules file size because it’s impossible to use the already loaded classes of the parentApplication.

Creating a generic ApplicationFaçade (in witch the getInstance method returns an IFacade instead a typed ApplicationFaçade instance) we got some interesting behavior. The module can be loaded within an Application that uses or not PureMVC and it’s behavior continues almost the same. If it had been loaded into an Application that uses PureMVC there is an issue with registered commands, mediators name, proxies name, and so on (they might override registered commands, mediators and proxies. Take a look at the example below).

I agree if we use the type of notifications we can prevent to process any notifications that we don’t want, but what about the registered commands, mediators and proxies (they probably will be overridden)?

We also thought about the possibility of constants name, mediators name and proxy name to be agreed (using the fully qualified name of class, so in this way they will not crash), but this is not that elegant solution (I think) and it could crash using external components (Softwarehouses) that uses PureMVC.

We think that the following solution could solve our problems:
    Step 1 - Creating an AbstractFaçade without Singleton behavior, we could have a ConcreteFaçade (each module would have his own Façade) that implements its own Singleton, solving the conflict issues using PureMVC in modules.
    Step 2 – We’ll need to change the implementation of the View, Controller and Model because we think they don´t need to be Singletons. The ConcreteFaçade already guarantees there will be only one instance of each one per Façade, resolving the conflict registration issues in Model,View and Controller.

The benefits using this solution are:
    - Components and Modules using PureMVC become blackboxes.
    - Intermodules communication will be possible without collateral effects (events or ShellFacade orchestration)

We know the importance of the Façade, Model, View and Controller in being Singleton classes. But does not sound that in this case each module has to get a unique instance of them (Façade, Model, View and Controller)?

Is there any way to do this (Modules + PureMVC) without changing the framework source?

Thank you,
Rodrigo and Diego Volpe.