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

Pages: [1]
Print
Author Topic: Modular Applications with PureMVC  (Read 11265 times)
rodrigo
Port to PHP
Newbie
*
Posts: 3


View Profile Email
« 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.
Logged
aridany
Newbie
*
Posts: 1


View Profile Email
« Reply #1 on: January 11, 2008, 03:33:33 »

Hi, take a look to this post:

http://forums.puremvc.org/index.php?topic=49.0

I have to say, this approach is promising. We are currently working in a sample project and we are trying this approach. Adding some changes we think we can load multiple modules, even multiple instances of the same module, without interactions and comunications between modules or between instances.

... 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)?

For that in this sample project, we are generating an unique uid for each module or instance. This uid is added to the names of the notifications, proxies and mediators. This prevents possible interactions.







« Last Edit: January 11, 2008, 04:38:45 by aridany » Logged
diegovolpe
Newbie
*
Posts: 7


View Profile Email
« Reply #2 on: January 11, 2008, 07:45:49 »

Hey Aridany, thanks for the tip.

I read all posts related to modules, but we couldn't find a solution for optimized modules in different projects (using same appDomain to share classes and decrease file size).

Changing the registration names was our first attempt (it really works), but it's not a reliable solution when you have to use third-party components (softwarehouses or when you don’t have access to the code).

There are some issues changing registration names:
  • Two different components sharing the same registration, proxy and note names (without source)
  • Creating instance UIDs will crash collaborative applications (record, transmit and replay) because it will be impossible to notify a "remote/local proxy" instance (eg.: record user interaction; save notifications; replay notifications in another application instance)

It sounds like criticism but it’s not. We’re massively using this awesome framework, but we’re facing some problems that are demanding framework changes and we don’t want to do that.

Hope we could find a nice solution.
Thanks
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: January 12, 2008, 12:21:17 »

Diego,

Modifying the framework to support modules goes against the grain.It would make no sense in Java, for instance.

I'm pretty ill today, so I am sorry I can't be of more help at the moment.

Please continue to post your thoughts/findings here and I will rejoin this as soon as I am able.

-=Cliff>
Logged
tjiddy
Jr. Member
**
Posts: 10


View Profile Email
« Reply #4 on: January 18, 2008, 04:54:48 »

I'm having a similar problem loading two independent applications.  One app determines at run time it needs to load another puremvc app.  As the second one is starting up, the facade is not created because getInstance  is static and sees that instance is not null (obviously following the singleton pattern very well).  I guess I'm just saying that along the lines of what has been suggested about modules, also applies to loading multiple projects (via SWFLoader).
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: January 18, 2008, 05:11:06 »

Have a look at this post by Zilet, who has a solution up for review:

http://forums.puremvc.org/index.php?topic=49.msg732#msg732

-=Cliff>
Logged
rodrigo
Port to PHP
Newbie
*
Posts: 3


View Profile Email
« Reply #6 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
Logged
Pages: [1]
Print