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/
