[osflash] Architecture of reusable modules with different view perproject
João Saleiro
joao.saleiro at webfuel.pt
Thu May 8 02:51:29 PDT 2008
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: joao.saleiro at webfuel.pt <mailto:joao.saleiro at webfuel.pt>
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 <joao.saleiro at webfuel.pt
> <mailto:joao.saleiro at webfuel.pt>> wrote:
>
> Iman,
>
>>
>>
>> If you post this question to the www.oodforum.com
>> <http://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
> osflash at osflash.org <mailto:osflash at osflash.org>
> http://osflash.org/mailman/listinfo/osflash_osflash.org
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> osflash mailing list
> osflash at osflash.org
> http://osflash.org/mailman/listinfo/osflash_osflash.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/osflash_osflash.org/attachments/20080508/db0e238f/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.gif
Type: image/gif
Size: 4901 bytes
Desc: not available
Url : http://osflash.org/pipermail/osflash_osflash.org/attachments/20080508/db0e238f/attachment-0001.gif
More information about the osflash
mailing list