Scott,
The sample app we have given you with the *alpha* of
Cairngorm 2.0, is not intended as documentation. The documentation of
Cairngorm is a separate effort - we have several articles forthcoming that will
be released in the weeks ahead. There are some guides at http://www.iterationtwo.com/open_source_cairngorm.htmlfor
Cairngorm 0.99 that might get you started; we also cover the Cairngorm concepts
in "Developing Rich Clients with Macromedia Flex" (Macromedia Press) and to a
lesser extent (since it's more focussed on Flash) in a chapter of the
ActionScript 2.0 Dictionary.
To perhaps answer your immediate question; it's a decision
left to the developer how they wish to manage view event handling; we are not
overly prescriptive in our approach with Cairngorm. Typically however, you
will want to manipulate your view when a Command has finished executing - either
in the execute() method, or in an onResult handler.
There are different strategies; some will choose to have a
ViewManagement class (and may even have an application-level ViewHelper that
they locate via the ViewLocator) that encapsulates the switching of view
states. Others will choose to keep the concept of state in the
ModelLocator (and perhaps even in a ViewState class of their own design, that
they hang off the ModelLocator) and bind their view-states (such as ViewStacks)
to the state held in the ModelLocator. Your approach will depend upon the
complexity of your views - a view state-machine is overkill for an application
with only a handful of views for instance.
In the very simple Login example, the state of a ViewStack
is a binding _expression_ that binds to a function:
mx:ViewStackid="appView"
selectedChild="{ getView( model.workflowState )
}"
The getView() method is as follows (in the main
application):
public function getView( workflowState : Number
) : UIComponent{ if(
model.workflowState == ModelLocator.VIEWING_LOGGED_IN_SCREEN
) { return
loggedIn;}
else { return
login; }}
So any
time the workflowState is updated in the ModelLocator (model), the binding for
the ViewStack will fire and re-evaluate which state the viewstack should be
in.
If you
look at the result handler for the LoginCommand, it takes responsibility for
updating the workflowState:
public function onResult( event : ResultEvent ) :
void { var
model : ModelLocator = ModelLocator.getInstance();
model.workflowState =
ModelLocator.VIEWING_LOGGED_IN_SCREEN;
model.loginDate = new Date();
model.loginVO = LoginVO( event.call.loginVO );
}
So,
when login success occurs, the LoginComand updates the state to
VIEWING_LOGGED_IN_SCREEN, which will cause your binding to fire in your
ViewStack, which will cause the getView() method to fire.
Hope
that makes sense.
Best,
Steven
Steven WebsterPractice Director (Rich
Internet Applications)Adobe ConsultingWestpoint, 4 Redheughs
Rigg, South Gyle, Edinburgh, EH12 9DQ, UKp: +44 (0) 131 338
6108
m: +44 (0)7917 428
947
--
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
Visit your group "flexcoders" on the web.
To unsubscribe from this group, send an email to:[EMAIL PROTECTED]
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
