Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought

Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Show Posts

* | |

  Show Posts
Pages: [1]
1  PureMVC Manifold / Bug Report / [ FIXED ] Notifier needs to implement INotifier on: February 07, 2008, 05:18:32
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?
2  Announcements and General Discussion / General Discussion / Re: Modular Applications with PureMVC on: January 30, 2008, 04:14:58
Hi folks,

Since last post we were thinking in a manner to solve the modules problem and also taking a look in all related posts in this forum.
In our case, one thing that really could cause conflict in the projects is the constants names.

So we wrote an extension of PureMVC to support flex modules.
The main idea is to ensure that modules constants names will not conflict and to do this a ModuleFacade manages the names implicitly (giving unique names).

There are not many code changes to do if we compare a module implementation based on this extension and the original PureMVC.
The main changes to do are:
 - Modules ApplicationFacade extends ModuleFacade and have to implement the singleton pattern. Optionally in the constructor you can pass this for the super constructor (so in this case the unique name will be based in the fully qualified name of ApplicationFacade).
 - Mediators extends ModuleMediator. The listNotificationInterests method return an array whith unique values calling super.getUniqueListNotificationInterests. The handleNotification method always call super.handleNotification.
 - Proxies extends ModuleProxy.
 - Commands extends ModuleSimpleCommand or ModuleMacroCommand. In case of extending ModuleSimpleCommand have to call super.execute(notification).

The inter-modules communication is done with the help of Orchestrators that know the Facades, Interfaces and the Events Constants of each module envolved.

We also needed a shell to load the modules which is the MainApp in the zip file. This MainApp has the responsibility to manage the modules and it Orchestrator (or orchestrators).

There is a lot of code in this zip file in the attachment bellow and it has also a readme.txt that explains the usage of each project.

Any feedback will be welcome.
Thanks a lot
3  Announcements and General Discussion / General Discussion / Modular Applications with PureMVC on: January 11, 2008, 11:11:55
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.
Pages: [1]