We are firm believers of precompiling our applications when in
production rather then using the JIT MXML compiler.  We are big
proponents of ANT and automate the builds of not only the MXML but of
the entire production server.  With one command line we build the
entire site ready to go into production.  Its very powerful and has an
immeasureable impact on productivity of our teams.  We've built some
very nice macros in ant that make building Flex applications very simple.

IMHO the JIT compiler is not how you want to run your production
application.

-- 
Dave Wolf
Cynergy Systems, Inc.
Macromedia Flex Alliance Partner
http://www.cynergysystems.com

Email:  [EMAIL PROTECTED]
Office: 866-CYNERGY

--- In flexcoders@yahoogroups.com, "fowleryj" <[EMAIL PROTECTED]> wrote:
>
> 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 
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/
 



Reply via email to