Hi Carlos, Actually the application I am developing (the one that started this thread) is built on Cairngorm.
In order to give the seperate modules access to Cairngorm and core application classes (ie models, commands) I have put our core application classes and the Cairngorm classes and in an RSL. This allows any of the modules to access all the key pieces of the main application. As each module gets loaded into the application shell, they register events/commands with the main application controller. As far as unloading goes I have not dealt with that (for now). In the application, modules only get loaded as users need them, but not unloaded. All in all it is a fairly straightforward process, BUT, you do need to have a really good architecture plan before you start because it can get a little confusing as to which pieces are where. Also, understanding RSLs and how to use external libraries is hugely beneficial. Derrick --- In flexcoders@yahoogroups.com, "Carlos Rovira" <[EMAIL PROTECTED]> wrote: > > Hi to all, > > I was following this thread with interest since there is very useful info. > > One thing that you are not talking about at the moment is about Modular > Cairngorm Apps. Cairngorm is a great framework for monolithic flex apps, but > if you try to modularize it you don't have the necesary artifacts to > accomplish the task (or maybe I can't find those). > > if you make a module, you should have a way to add commands and add services > on the fly. And the same as you remove a module you should have a way to > unregister commands and services. Maybe the shell application should build > the main MVC structure and let modules contribute its own commands, services > and so on as soon as are loaded. But it seems that nothing of this are taked > into account in the microarchitecture. Maybe that would be a topic of > interest for many people and a subject fot Steven, Ali and others next > article. > > Maybe someone has invest time in this subject? > > Best, > > C. > > > > On 9/28/06, Anatole Tartakovsky <[EMAIL PROTECTED]> wrote: > > > > Paul, > > *>>* > > *Certainly. The caching issue I'm referring to is when a new RSL SWF is > > published and pushed to a server the end user may not immediately see > > the new SWF. Or, more accurately the users browser may load the old > > version of the SWF from the browser cache and not the more recent from > > the server. > > <<* > > I think browser cache should recognise new RSL. You can use any HTTP > > tracer to verify that every application startup causes appropriate HTTP > > request and get 304 and 200 codes. I am not aware of any problems so far. > > >> > > *Certainly. The caching issue I'm referring to is when a new RSL SWF is > > published and pushed to a server the end user may not immediately see > > the new SWF. Or, more accurately the users browser may load the old > > version of the SWF from the browser cache and not the more recent from > > the server. > > *<< > > I would like to confirm that there is a problem first. Also, please refer > > to initialize method for Preloader object - by subclassing it you can mangle > > URLs any way you like. > > > > Sincerely, > > Anatole > > > > > > On 9/27/06, Paul Spitzer <[EMAIL PROTECTED]> wrote: > > > > > > Anatole Tartakovsky wrote: > > > > Paul, > > > > Could you please clarify your question - it seems that there are > > > > number of issues that are mixed up here. First, there is no issue of > > > > RSL caching in the browser unless you specifically enable some > > > > expiration scheme. > > > > > > Certainly. The caching issue I'm referring to is when a new RSL SWF is > > > published and pushed to a server the end user may not immediately see > > > the new SWF. Or, more accurately the users browser may load the old > > > version of the SWF from the browser cache and not the more recent from > > > the server. > > > > > > Does that make sense? > > > > > > > > > > > I have seen people loading multiple applications side by side - using > > > > the same RSLs - that is essentially the question if you want to > > > > isolate your runtime libraries in case of versioning in the future - > > > > that would essentially hurt performance > > > > > > > > Finally, there is an issue of loading RSLs in the root appDomain - > > > > essentially you do not have a chance to do reloading of the classes > > > > till the application startup. Also, there is obvious problem with > > > > versioning. > > > > > > > > Seems we are done with the client - now the question is how to build > > > > RSLs so it is the smallest, most recent, and up to date one. > > > > > > > > That's were it breaks in the beginning. Essentially, if you are using > > > > dynamic instantiation of any class in the RSL, the main application > > > > would not know whic objects to initialize/which dependent classes to > > > > include. One solution we are using is to build self initializing > > > > modules and use them instead of RSLs that would of been extracted out > > > > of SWCs by the build process. > > > > > > I was just discussing a similar option with a coworker here. The idea is > > > > > > that instead of using RSLs we'd simply build libs of code (packaged in a > > > > > > SWF) and write our own loading scheme. Going this route, while more > > > work, would also allow us to control caching by appending a version to > > > the URL when loading.... corelib.swf?v=1. > > > > > > Thanks for taking the time to reply. > > > > > > > > > > > HTH, > > > > Anatole Tartakovsky > > > > > > > > > > > > > > > > > > > > > > > > On 9/26/06, *Paul Spitzer* <[EMAIL PROTECTED] <paul%40fluid.com> <mailto:[EMAIL PROTECTED]<paul%40fluid.com>>> > > > > > > > > > > wrote: > > > > > > > > >some concerns about potential RSL caching and how to overcome that > > > > >(I think it can be easily overcome with a proper rollout strategy) > > > > > > > > I'm curious to hear what your plan is to deal with the caching of > > > > RSL(s). Or how others deal with it. Any suggestions? > > > > > > > > derrickgrigg wrote: > > > > > I actually was concerned about the HOW and the WHY. I wanted to find > > > > > > > > out why doing it that way was a good solution or why someone else's > > > > > solution would be better or more viable. And if the proposed > > > > > solution was good, was how I intended to implement that solution the > > > > > > > > right way. > > > > > > > > > > I completely agree that having Abstract and Interface classes just > > > > > to accomplish modularity is basically creating a code management > > > > > problem. The only reason it was seriously being considered was to > > > > > allow the development of seperate module swfs, that need to use the > > > > > same base classes (ie models, command and value objects), without > > > > > having to worry about code duplication and errors/conflicts when > > > > > module swf are being loaded in the main shell application. > > > > > > > > > > I've had problems in the past with Flash and RSLs plus I still have > > > > > some concerns about potential RSL caching and how to overcome that > > > > > (I think it can be easily overcome with a proper rollout strategy), > > > > > so I was a little hestitant to pursue that idea. However, from your > > > > > post and Erik's (plus my own nagging suspicion), I think having the > > > > > base code in an external SWC and using that as an RSL is the right > > > > > was to go. > > > > > > > > > > Derrick > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > ::| Carlos Rovira > ::| http://www.carlosrovira.com > ::| http://www.madeinflex.com > -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
