Hi João,

 

To me it's not completely clear in what you’re trying to accomplish (apart
from code reusability). What's the real problem you're dealing with? To me
it sounds your biggest problem is the actual view management and the
flexibility in moving views. Which I believe is the problem everyone is
dealing with!

 

ARP and Cairngorm do not give me the view management I’m looking for! To me
they are only good for data separation / business logic. There is always a
bunch of things that need to be changed when switching views (and preferably
in a specific order). To me a notification from the model is not sufficient
enough. 

 

I must admit, I haven't looked at PureMVC yet (to me it looks quite complex
to get a grip on). But whenever I'm dealing with complex views (and
sequences) there is only one thing out there that supports my needs and
that's the Gugga task principle. The basis of Gugga’s taskmanagement is the
ITask interface, which is as easy as 123! Modeled after that simple
interface we have all kinds of predefined tasks, but the most important ones
are TaskManager and TaskSequence. 

 

Check out the diagrams on the Gugga blog and see if this is the complexity
you’re trying to manage within you’re views:

 
<http://www.gugga.com/flashblog/2006/10/basics-of-tasks-and-sequences-in_20.
html>
http://www.gugga.com/flashblog/2006/10/basics-of-tasks-and-sequences-in_20.h
tml

 

And download the examples here:

 <http://www.gugga.com/GuggaFlashFramework/>
http://www.gugga.com/GuggaFlashFramework/

 

I promise, once you get a real grip on it, you don’t want to look back on
what you we’re doing before.

 

Yours, Sander


  _____  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of João Saleiro
Sent: woensdag 7 mei 2008 18:52
To: Open Source Flash Mailing List
Subject: [osflash] Architecture of reusable modules with different view
perproject


Hello,

I am starting now with PureMVC. I was a Cairngorm adept (and before that,
ARP), 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


-- 

         João Saleiro 

Email/MSN:  <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]
Skype: joao.saleiro
Tel: +351 916 077 097 / +351 968 203 370
WWW:  <http://www.webfuel.pt> http://www.webfuel.pt     

<<logo.gif>>

_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org

Reply via email to