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: Architecture of reusable modules with different view per project  (Read 6364 times)
joao.saleiro
Newbie
*
Posts: 6


View Profile Email
« on: May 07, 2008, 09:51:08 »

Hello,

I am starting now with PureMVC. I was a Cairngorm adept (changed from ARP when Flex 2 appeared), but Cairngorm failed me when I started working more and more with Modules.

I studied PureMVC with the multicore examples, and both the architecture and workflow convinced me.  I am not 100% comfortable with PureMVC yet, but I'm already testing it on a real project.

I am trying to improve code reusability, and I need some advices to achieve a best-practices solution to the problem I'll describe below. This might be a common problem when someone starts building larger projects, while reusing code, and maintaining the smallest dependencies possible between modules. I'll try to explain with an example.

We have organized our workflow for reusing code between projects the following way:

- we have a folder where we put everything that's needed among several projects (our library);
- in each project we add the library to the classpath of the project.

For example, about 90% of our projects need a custom "LocaleManager " module. A LocaleManager is something composed with a view, a model and a controller, that allows users to add new languages to our RIAs. The functionality is 100% equal in every application. So we decided to create a Module that resides on our library path, and the Module has it's own MVC architecture based on PureMVC multicore.

The thing is that while the functionality is 100% the same in every application, the view might change. Not only in terms of (css) style, but also in terms of what and how things are shown to the user.

So I thought in removing the View from the MVC of the Module, putting it on the Main application, and when I load the Module I would inject the view.  I created an IViewReceiver that my Module implements, with a function inject(mediator:IMediator, addView:Boolean):void .
The implementation of this function would consist on registering the mediator on the facade of the Module, and making and addChild of the mediator.getViewComponent() if the addView flag equals true. If my module has more than one component, I have to call the inject method for each component I want to register with the Module' Facade.

I am implementing this right now, but I'm not sure if it's the best option, and even if it works. I wonder if there is a established best-practice out there for this case. Do you think that my solution will work? Is there a better one?

Summarizing, what I need is to have modules in a library shared between projects; Each module is almost a full application, without the view (it can have the view coded on the same packaged, but it's not included by default) so it's a MVC without the V; The guy who creates the Application that uses the module must have the possibility to create it's own view for that module; The modules must be independent of the applications where they are used, but the applications can be dependent on the modules.

Thank you,

João Saleiro
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: May 07, 2008, 05:38:20 »

Injecting the display object into the module seems perfectly reasonable.

In the Modularity demo its just reversed, the Module injects a view component into the main app (via the shell interface method addComponent. 
No reason not to do it the other way around.

-=Cliff>
Logged
Pages: [1]
Print