If one goal is to have independent modules then I would do this: A Module will contain the M-V and C parts the ModuleLoader will have a smart proxy M,V and C which contain logic that knows when to defer to a particular Modules M-V- or C.
On Thu, May 8, 2008 at 2:51 AM, João Saleiro <[EMAIL PROTECTED]> wrote: > I don't agree. Modules should be independent of the architecture of the > applications where they are used. Your solution would force the modules to > be used only on Applications based on MVC. > > Before trying PureMVC multicore, I have tried Modular (for cairngorm) and > FlexCairngorm. The architecture was the one you proposed, but I wasn't happy > to create modules that could only be used on MVC applications. > > I still prefer my architecture, but opinions on my solution would be > great. :) > > João Saleiro > > > João Saleiro > > Email/MSN: [EMAIL PROTECTED] > Skype: joao.saleiro > Tel: +351 916 077 097 / +351 968 203 370 > WWW: http://www.webfuel.pt > > > Iman Khabazian wrote: > > I agree this is a common issue. > I think you are on the right track. > If it was me I would do something like this (which is similiar to what you > describe). > > You have 1 container that runs pureMVC. > > Usually within PureMVC you must register serveral mediators, several > CommandClasses (including command classes that prep the model and view). > To support modules I would think you should create a mechanism to inject > these registrations at run time. > > Whether you can get more reusability by including V or just the M and the > C is your choice, but I would replace the hardcoded registrations with a > dynamic one that uses objects that come from the module being used. > > More specifically the module should expose functionality that allows the > applicationFacad to iterate through a Mediator Factory and a Command Class > factory. Your applicationFacad should iterate through each module and for > each module iterate through the factories to get all of the objects that > will be registerd. > > Does seem right? > > > > On Wed, May 7, 2008 at 5:15 PM, João Saleiro <[EMAIL PROTECTED]> > wrote: > > > Iman, > > > > > > > > If you post this question to the www.oodforum.com with more information > > and an example I will try to give you a more exact solution. > > > > > > what if I post more information here on osflash, will you give me a > > more exact solution? :) > > > > I am setting up an ecosystem for building several large-scale enterprise > > RIAs. Each RIA can be composed by one or several Modules. I am not worried > > right now with having different SWF's (aka Flex Modules), but with > > encapsulating modules for reusability and maintainability. > > Each module is responsible for a part of the application. For example, > > managing registered users. So a module can add users, remove, update, etc. > > Each module has it's own MVC architecture, so I needed a multi-core > > framework to solve the problem of having multiple singletons. > > I can have different teams working on a different module, and testing it > > without depending on the application. > > > > Normally these modules are never the same between projects. There are > > always slight differences between businesses so it's hard to reuse a full > > module (in another words, import the module from a shared library path and > > use it as it is) > > > > But there are also modules that are always the same between projects. > > For example, our LocaleManager that allows the user to add new languages to > > the RIA and create custom localizations. So we have for example our > > application on the package com.application and the module on the package > > pt.webfuel.modules.locale . > > > > Until this point everything's fine. The problem starts when we want to > > reuse the module on different projects, but the view is different on each > > project. The behaviour (controller) is the same , the proxys and VO's are > > the same (model), but the view is different. > > The solution I come with involves keeping the MC parts of MVC on the > > module, and making the V (components+mediators) part on the application, > > allowing it to inject the view on the module. My module implements an > > IViewReceiver so it has a method injectView(mediator:Mediator).This method > > will register the view on the ApplicationFacade of the module. > > If I want to use the same view on several projects, I also can. I just > > need to put the view on the package of the module, and the application just > > injects that specific view. > > > > This way I can reuse modules between projects, but with completey > > different views. What's shared is the data (model) and behaviour > > (controller). > > > > Of course, the application needs to know the "core" of the module (the > > framework) since it's the application that has the implementation of the > > mediator of the module's view. I don't see a problem there. Also, the module > > knows nothing about the application, so it's also fine to me. The thing is > > that: > > > > - This is just my solution, that isn't fully implemented so I > > haven't tested on a real situation; > > - This is probably a common problem... and normally for common > > problems there are common solutions. Is there other solutions? > > > > BTW, for those who don't know PureMVC, one of the best things of the > > framework is that the views are 100% independent of the framework. There are > > also some other "details" I like (multicore, being platform independent, > > simple structure), but I still haven't tested it fully on a production > > project. If there is interest, after I get better with PureMVC I can make a > > review from the point of view of an old ARP/Cairngorm addict. :o) > > > > Thanks, > > > > João Saleiro > > > > _______________________________________________ > > osflash mailing list > > [email protected] > > http://osflash.org/mailman/listinfo/osflash_osflash.org > > > > > ------------------------------ > > _______________________________________________ > osflash mailing [EMAIL > PROTECTED]://osflash.org/mailman/listinfo/osflash_osflash.org > > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org > >
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
