That would be fantastic Alex. Thank you for your thoughts concerning this topic. I look forward to reading your blog.
-TH --- In [email protected], "Alex Uhlmann" <[EMAIL PROTECTED]> wrote: > > Hi there, > > I'd suggest letting the Command retrieve a model object via > ModelLocator. Then, some state property in the model changes which could > trigger an event. Views could listen to either EventDispatcher events or > via Bindings. Following the Binding approach, your view could bind to > single properties, call methods on the view via function bindings or if > you explicitly want to let the view react to a model's state change with > calling a view method (i.e. invoking an effect or popup), which doesn't > necessarily return a value to a MXML component, you can use mx:Binding > or Paul's Observe tag. > http://weblogs.macromedia.com/paulw/ > Tim, you're right. I'll hopefully get to post something about this later > this week. > > Best, > Alex > > Alex Uhlmann > Consultant (Rich Internet Applications) > Adobe Consulting > Westpoint, 4 Redheughs Rigg, > South Gyle, Edinburgh, EH12 9DQ, UK > p: +44 (0) 131 338 6969 > m: +44 (0) 7917 428 951 > [EMAIL PROTECTED] > http://weblogs.macromedia.com/auhlmann > > > > ________________________________ > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Tim Hoff > Sent: 18 September 2006 04:29 > To: [email protected] > Subject: [flexcoders] Re: cairngorm: calling a function in a view > > > > 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] <mailto:flexcoders% 40yahoogroups.com> > , "Diego Guebel" > <dguebel.subscription@> 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 <TimHoff@> 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] > <mailto:flexcoders%40yahoogroups.com> , "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 > <http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt> > > > Search Archives: http://www.mail-archive.com/flexcoders% > <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/
