Yes, your login example illustrates a common way to drive the view through the ModelLocator. However, I agree with you that it would be cleaner to have a view method to do this sort of thing instead of a huge model with lots of references. The only problem with referencing a view function directly from a command, is that if you remove the view or the function, the command breaks (violates encapsulation). If you really wanted to do this from a command though, you could traverse the display list ID's like so (not recommended):
Application.application.viewMain.viewRef.resetForm(); An alternative would be to dispatch a custom event, from the command, that would be listened for by the view. I've addressed this issue here before. My personal opinion is that a responder that goes from the command, through the FrontController, to the view, would be very helpful for these types of functions. The Cairngorm experts here haven't really provided much guidance, either through samples or blog postings, in this area. Perhaps as more people, like you, ask similar questions, more insight will be provided. Until then, since we want to remain as true to the Cairngorm architecture as possible, binding all state (local and shared) to the ModelLocator seems to be the recommended solution. Thanks for the post, -TH --- In [email protected], "Diego Guebel" <[EMAIL PROTECTED]> wrote: > > Hi Tim, > this might be a silly example: > I have a login form, when the command responds onFault I want to able to > reset the user and password textfields. > doing something like: > viewRef.resetForm(); > > you might suggest to do something like this in the view: > <mx:TextInput id="username" text="{login.username}"/> > <mx:TextInput id="password" text="{login.password}"/> > > and something like this in the command: > public function onFault(event:* = null):void > { > model.login.username = ""; > model.login.password = ""; > } > > I think this is the best practice, but I was just wondering as I'm moving > from Arp where you have a view reference in the command and is really > common to do things like viewRef.method() > something I think it would be clearer to have a method to do this sort of > thing instead of a huge model with lots of references.... > > Diego. > > > On Mon, 18 Sep 2006 10:17:41 +1200, Tim Hoff <[EMAIL PROTECTED]> wrote: > > > Hi Diego, > > > > In general a Command and a View shouldn't know about each other. > > Usually, the state of a view is changed by binding to the > > ModelLocator; which is updated by a Command. What does your view > > function do? > > > > -TH > > > > --- In [email protected], "Diego Guebel" > > <dguebel.subscription@> wrote: > >> > >> Hi there, > >> I wonder what would be the best way to call a function in a view > > when I > >> get a result in a command. > >> what is the way to have a reference to the view in the command > > since > >> viewlocator/viewhelper is not more recommended? > >> Thanks, Diego. > >> > > > > > > > > > > > > > > > > -- > > 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 > > > > > > > > > > > > > > > > > -- 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/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> 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/
