|
List Info
Thread: Architecture of reusable modules with different view per project
|
|
| Architecture of reusable modules with
different view per project |
 
Portugal |
2008-05-07 11:52:29 |
|
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
|
 |
| View Original Image |
| Re: Architecture of reusable modules
with different view perproject |
 
Netherlands |
2008-05-07 15:58:17 |
|
Hi
Joćo,
To me
it's not completely clear in what youre 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 Im 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 Guggas 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 youre
trying to manage within youre views:
http://www.gugga.com/flashblog/2006/10/basics-of-tasks-and-sequences-in_20.html
And
download the examples here:
http://www.gugga.com/GuggaFlashFramework/
I promise, once you get
a real grip on it, you dont want to
look back on what you were doing before.
Yours,
Sander
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
|
 |
| View Original Image |
| Re: Architecture of reusable modules
with different view perproject |
|
2008-05-07 16:30:16 |
|
Hi
Joćo,
I have been using PureMVC and it is definitely a great platform. It allows
for easy reuse of View Components.
To me pureMVC is all about writing custom Mediators, Command Classes and Proxies to handle View Components(and the reuse of view components). The ironic/great thing is in PureMVC you shouldn9;t even touch the Model, View or Controller.
It sounds like you would like to bundle the View Component along with the custom Mediators, Command Classes and Proxies in a "Module" because you see opportunities to reuse to bundle.
Is this correct?
If it is the case then why don't you create a "Module" that points to the bundelled classes and create a mechanism that registers a "Module" and switches between modules inside multicore pureMVC.
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.
Thanks,
Iman
On Wed, May 7, 2008 at 1:58 PM, Sander Wichers < developmen t wichers.nu">developmentwichers.nu> wrote:
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
And
download the examples here:
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: osflash-bouncesosflash.org" target="_blank">osflash-bouncesosflash.org
[mailto: osflash-bouncesosflash.org" target="_blank">osflash-bouncesosflash.org] 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
_______________________________________________
osflash mailing list
osflashosflash.org">osflashosflash.org
http://osflash.org/mailman/listinfo/osflash_osflash.org
|
| Re: Architecture of reusable modules
with different view perproject |
|
2008-05-07 20:25:29 |
|
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.salei rowebfuel.pt">joao.saleirowebfuel.pt> 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
VO9;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. 
Thanks,
Joćo Saleiro
_______________________________________________
osflash mailing list
osflashosflash.org">osflashosflash.org
http://osflash.org/mailman/listinfo/osflash_osflash.org
|
| Re: Architecture of reusable modules
with different view perproject |
|
2008-05-08 12:31:22 |
|
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 < joao.salei rowebfuel.pt">joao.saleirowebfuel.pt> wrote:
I don't agree. Modules should be independen t 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
wasn9;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.
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
& lt; joao.saleirowebfuel.pt" target="_blank">joao.saleirowebfuel.pt>
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 informatio n 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
VO9;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.
Thanks,
Joćo Saleiro
_______________________________________________
osflash mailing list
osflashosflash.org" target="_blank">osflashosflash.org
http://osflash.org/mailman/listinfo/osflash_osflash.org
_______________________________________________
osflash mailing list
osflashosflash.org">osflashosflash.org
http://osflash.org/mailman/listinfo/osflash_osflash.org
|
[1-5]
|
|