|
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 -----
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
YAHOO! GROUPS LINKS
|
