Yup absolutely. We use RSL's a lot, and have all that rolled into our ANT tasks that do the builds. On big applications, like we have, they can make a significant difference.
-- Dave Wolf Cynergy Systems, Inc. Macromedia Flex Alliance Partner http://www.cynergysystems.com Email: [EMAIL PROTECTED] Office: 866-CYNERGY --- In flexcoders@yahoogroups.com, "Anatole Tartakovsky" <[EMAIL PROTECTED]> wrote: > > For large applications I believe you have to do a bit of refactoring and start playing with RSLs. > Aside of the obvious reasons of performance gain during development by eliminating unnecessary recompilation it kind of force you to eliminate weak links and create "layered" components - based view of the application. It might save additional time if/when the team/project grows to extent that versioning and areas of responsibilities would make single SWF not practical. > HTH, > Anatole > ----- Original Message ----- > From: fowleryj > To: flexcoders@yahoogroups.com > Sent: Monday, January 23, 2006 2:20 PM > Subject: [flexcoders] Re: Cairngorm Question > > > Hi Robin, > > Thanks again for all of the help so far. > > The next question I have is for any and all Flexcoders whose > application is growing to a rather large size (100s of files, etc). > How are you keeping your compile time down? Our application takes > between 30 seconds to 1 minute to refresh, and this seems rather high. > > Thank you, > YJ > > ------------ > > On Fri, 20 Jan 2006 11:22:03 +1100, Robin Hilliard wrote: > > We usually just bind the reference to the viewHelper down through the > UI components, e.g. > > <registrar:TabTwo label="tab2" viewHelper="{viewHelper}"/> > > Remember that our model is kept in instance variables of the > viewHelper. The viewHelper itself is either: > > (a) instanciated as a tag in the mxml, or > > (b) in our current implementation we have a singleton workspace > viewHelper with methods to: > * create new viewHelper instances of various types, and > * methods to create workspaces of corresponding types. > In this current implementation have two sorts of commands - > LaunchSearchCommand (creates a search in a new workspace) and > SearchCommand (does a vanilla search and sends results to the view > helper you pass to it). LaunchSearchCommand.execute() gets a new > SearchViewHelper from the workspace view helper (simple Factory > pattern), broadcasts a Cairngorm event to SearchCommand passing the > viewhelper it just got and the search criteria, and then calls the > workspace view helper again to create a new search workspace view > (spotyoursubappsgo.addChild(yourWorkspaceView, null, "", > {viewHelper : viewHelper}), again passing the new view helper. This > means that the server request and the creation of the new workspace > happen in parallel, and the timing of the return from the server > (before or after the view has finished rendering) doesn't matter, > because the viewHelper is ready to accept the server result, and the > view will bind to the model in the viewHelper in its own time. > Lastly (you don't have to do this) every view helper has a > corresponding interface in the commands package e.g. > ISearchViewHelper that the commands use to avoid depending on a > concrete view helper implementation - the workspace view helper > method return types are all in terms of these interfaces. > > Sorry to give such a rushed description, it really needs some > interaction diagrams to make it a bit clearer but hopefully you get > the idea. > > Cheers, > Robin > > PS: BTW I don't mind doing this on-list, other people might find it > useful. > PPS: I hope to make it to some US conferences this year, so I'll take > you up on the drinks :-) > > ______________ > > Robin Hilliard > Director - RocketBoots Pty Ltd > Professional Services for Macromedia Technologies > http://www.rocketboots.com.au > > For schedule/availability call Pamela Higgins: > w +61 7 5451 0362 > m +61 419 677 151 > e [EMAIL PROTECTED] > > or Direct: > m +61 418 414 341 > f +61 2 9798 0070 > e [EMAIL PROTECTED] > > *** Register for WebDU http://www.mxdu.com 2-3 March 2006 *** > > > On 20/01/2006, at 6:52 AM, fowleryj wrote: > > > Hi Robin, > > > > We've started implementing your ideas to solve the "multiple > instances > > problem." Forgive me for the continued questions, but we're wondering > > how you are handling the propagation of the data contained in the > > onResult() method in the Command. > > > > For instance, one of our sub-applications is laid out in the > following > > manner (with generic names and labels in this case): > > > > FileOne.mxml > > <mx:HBox> > > <mx:ViewStack> > > <search:SearchScreen id="searchScreen" label="Open"/> > > <mx:Panel id="infoPanel" label="Information"> > > <mx:TabNavigator id="tabNavigator"> > > <view:TabOne label="tab1"/> > > <registrar:TabTwo label="tab2"/> > > </mx:TabNavigator> > > </mx:Panel> > > </mx:ViewStack> > > </mx:HBox> > > > > So in FileOneViewHelper.as, we broadcast an event to find the results > > of the user's search criteria, and in the Command's onResult(), we > > call the particular view helper's (in this case, FileOneViewHelper's) > > handleEvent() method, passing it the necessary data. > > > > Once the user selects the match they want to work with, we need to > > propagate that match's data to the tabs in the TabNavigator, so that > > the tabs can fill themselves appropriately. Previously we were doing > > this by broadcasting an event, but now we are faced with the issue of > > passing the data along to the various tabs (TabOne and TabTwo, for > > instance) from the "parent" ViewHelper. We've explored a few options > > and they all seem to involve significant amounts of hardcoding to > > drill down through the hierarchy. If it's not too much to ask, would > > you share with us your method of passing the data from - for example > - > > a TabNavigator to its tabs? > > > > Thank you again for all of the time you've spent helping us with > this. > > If you ever find yourselves in the Southern United States, drinks are > > on us. :) > > YJ > > > > > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com > > > > SPONSORED LINKS Web site design development Computer software development Software design and development > Macromedia flex Software development best practice > > > ------------------------------------------------------------------------------ > YAHOO! GROUPS LINKS > > a.. Visit your group "flexcoders" on the web. > > b.. To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > > ------------------------------------------------------------------------------ > -- 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/ <*> 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/
