We had no problems implementing a system similar to your
description: One 'portal' app loads multiple mudular 'sub-apps'
at runtime. Each is standalone cairngorm app. As you said,
however, the biggest gotcha is one big shared ServiceLocator at
the main app level. In our case, wasn't big deal, as I think
there's only about one remote object per module, for us. Not much
more, anyhow, as each is a full controller / for the respective
service on the back-end. Wouldn't be hard to implement your own
ServiceLocators that impl same interface, but allows you to have
one per module, and could be their own Singletons. It' just an
odd setup, as they wanted to implement an MXML definition for
services.
On Wed, Apr 9, 2008 at 7:05 PM, João Saleiro
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Hey guys,
I am working on a Flex application based on Cairngorm. The
application
will be divided in modules for the purpose of distributing
only the
modules clients request. There will be a configuration tool
on the
application to "install" new modules, and manage existing
ones. The
motivation for using modules is to manage properly the
complexity of the
application while it grows and to help managing the roles on
the team
assigning each module to different persons.
The first question is whether I should have:
a) One Flex Project that has the application and several modules;
b) One Flex Project for each module and another for the
application;
c) One Flex Project for all modules, and another for the
application;
I think the best option is to go with b). What do you think?
Second question: which of the following seems a preferable
practice:
a) Only the application uses MVC
b) The application and each module have it's own MVC architecture
I would go with option b). The problem is that MVC has some
Singletons
and that will create problems, since I would have, for
example, one
Controller for the application and another for each Module.
To solve this problem, I can use Modular -
http://lab.arc90.com/2007/10/modular_1.php
Modular will work as a proxy for the Controller, allowing to
register
new commands on runtime on the main application controller. Those
commands will be defined on my Module. In terms of use, it seems
practical and logic to me, but in terms of architecture, it
seems a bit
wrong to me - wouldn't it be preferable if each module had
it's own
controller? Why should the module depend so much on the
application that
uses it? What happens if the module is used on an application
that
doesn't use Cairngorm?... It's a bit questionable if Modular
should be
used or not.
Anyway, even if I went with this option, Modular doesn't
provide a
solution for the ServiceLocator. So, this leads me to another
question:
a) Only the application knows the backend and the services
provided by
the backend; So, there will be only one ServiceLocator and
all the
ServiceDelegates will be defined on the main application.
b) Each module knows the backend, and each module has it's own
ServiceLocator and specific ServiceDelegates for the remote
services
needed on that module.
I think the option b) seems more elegant to me. The problem
is that the
ServiceLocator implemented on Cairngorm is a Singleton, and
the same
happens with the ModelLocator. Since our implementations
extend the
classes on Cairngorm, even if I create "different"
ServiceLocators for
each module, that won't solve the problem since they are all one
instance - they all extend the same ServiceLocator class. And
I need one
ServiceLocator per module. I could solve that by not
extending the same
base class... but this doesn't sound correct to me, since I
would have
to replicate the ServiceLocator code on each module... Can
you propose
another solution?
I think there is lack of information on best-practices for
developing
big modular applications using modules and MVC. I am a bit
stuck right
now, since I need to make some important decisions on
architecture
before starting the development, and I do not want to change
all the
architecture later. Your opinion would be extremely helpful
to me!
Thank you!,
João Saleiro
_______________________________________________
osflash mailing list
[email protected] <mailto:[email protected]>
http://osflash.org/mailman/listinfo/osflash_osflash.org
--
: : ) Scott
Helping your grandma on the interweb
at: http://blog.criticalpile.com
------------------------------------------------------------------------
_______________________________________________ osflash mailing
list [email protected] <mailto:[email protected]>
http://osflash.org/mailman/listinfo/osflash_osflash.org
