Our sub-apps were indeed Module classes. Only coupling was on the ServiceLocator, but as I said, in our example, it was a pretty small file, anyhow.
I'm not sure what you're referring to, by Modular. We didn't have problems with Module(s) accessing Delegates, as they were defined in the Module. On Thu, Apr 10, 2008 at 5:02 AM, João Saleiro <[EMAIL PROTECTED]> wrote: > Thank you for your answer. When you said you had several "sub-apps", > those were Modules or Applications? I have seen people using Applications > instead of Modules, because they felt more comfortable while testing - but > this way they end up with bigger SWF's. > > Having the services on the Main App won't create a tight coupled > architecture between the module and the app ? > > In your architecture, have you used Modular? If yes, when you need to have > a command (which is defined on the module) that calls a ServiceDelegate > (which is defined on the application) how do you solve the problem that the > Module doesn't know the ServiceDelegate?. > > > Thanks, > > João Saleiro > > > sLangeberg wrote: > > 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]> > 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] > > http://osflash.org/mailman/listinfo/osflash_osflash.org > > > > > > -- > : : ) Scott > > Helping your grandma on the interweb > at: http://blog.criticalpile.com > > ------------------------------ > > _______________________________________________ > osflash mailing [EMAIL > PROTECTED]://osflash.org/mailman/listinfo/osflash_osflash.org > > > _______________________________________________ > osflash mailing list > [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] http://osflash.org/mailman/listinfo/osflash_osflash.org
