...Tim gave better examples than I did. A lot of those small, GUI operations are what I'm talking about.
----- Original Message ----- From: "Tim Hoff" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, July 10, 2006 8:00 PM Subject: [flexcoders] Re: Cairngorm Responder interface changes Hi Steven, Sorry to offer my .02, but here is a use-case: A search view component includes a TextInput for the search string, a RadioButtonGroup that is used for the search type selection, and two DateFields used for a search date range. There is also a search button and a reset dates button. When a search is performed, a responder returns a service call result to the command. The command updates the ModelLocator which automatically updates the view through binding. This works great for the heavy lifting (data, view states..). But, what about the light lifting; If results found: (clear and setFocus to the TextInput control, reset search options RadioButtons, reset the DateFields for a new search), If no results found: (do not reset fields, display a message saying "no results found for the search," prompt the user for additional information, launch the sound of laughing.mpg). :) Sure, in one way or another, all of this can be accomplished with binding to variables in the ModelLocator, Alerts and PopUps. But, inho, binding state for the small things, that are soley related to a local view and conditional on the result of the call, serves to clutter-up the ModelLocator. The view could handle some of its own state if it was notified of the status of the service call. I know that this is purely preferential, but why use the ModelLocator to control every single state in the application, when a local view could handle the small stuff? By reducing the number of state variables, the views would also be easier to reuse; if, for instance, you wanted to encapsulate the view by passing-in the bindings to the ModelLocator in the components outer definition. Proposal: Round-trip notification - success, failure, or custom message returned to the originator of the CairngormEvent (sans data). Possible method: Add a ViewResponder class that passes messages between the Command and the View; based on the result returned by the service Responder. Or, how about attaching the Responder to the CairngormEvent to create a front-to-back, full-duplex pipeline for the call. If I'm totally off-base with this, please disregard. Humble regards, Tim Hoff --- In [email protected], "Steven Webster" <[EMAIL PROTECTED]> wrote: > > jesse, > > sorry if you've covered this already; but what do you mean by commands > supporting callbacks, in terms of an example usage of where you'd do > this ? can we rewind to the use-case, so I can make sure I understand > what you're trying to achieve here ? > > best, > > Steven > > Steven Webster > Practice Director (Rich Internet Applications) > Adobe Consulting > Westpoint, 4 Redheughs Rigg, South Gyle, Edinburgh, EH12 9DQ, UK > p: +44 (0) 131 338 6108 > m: +44 (0) 7917 428 947 > [EMAIL PROTECTED] > > > > > ________________________________ > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of JesterXL > Sent: 06 July 2006 21:11 > To: [email protected] > Subject: Re: [flexcoders] Re: Cairngorm Responder interface > changes > > > > ...or you can have Commands support callbacks, and thus no need > for state > variables, nor a need for your Commands to update those > variables. > > ----- Original Message ----- > From: "Steven Webster" <[EMAIL PROTECTED] > <mailto:swebster%40adobe.com> > > To: <[email protected] > <mailto:flexcoders%40yahoogroups.com> > > Sent: Thursday, July 06, 2006 3:57 PM > Subject: RE: [flexcoders] Re: Cairngorm Responder interface > changes > > Agreed. Developers *have* to take responsibility for creating > application-specific classes. If your application has "10 > million state > variables", then having a StateMachine / StateManager seems like > a > logical refactoring to aim for. If however, your application has > "a > decent number of states", no reason they can't be held in a > single State > class kept on the model (our typical solution), and if you only > have 2 > or 3 states, even the State class can be overkill. > > Just my $.02 > > Steven > > Steven Webster > Practice Director (Rich Internet Applications) > Adobe Consulting > Westpoint, 4 Redheughs Rigg, South Gyle, Edinburgh, EH12 9DQ, UK > p: +44 (0) 131 338 6108 > m: +44 (0) 7917 428 947 > [EMAIL PROTECTED] <mailto:swebster%40adobe.com> > > > -----Original Message----- > > From: [email protected] > <mailto:flexcoders%40yahoogroups.com> > > [mailto:[email protected] > <mailto:flexcoders%40yahoogroups.com> ] On Behalf Of Tom Chiverton > > Sent: 06 July 2006 16:01 > > To: [email protected] > <mailto:flexcoders%40yahoogroups.com> > > Subject: Re: [flexcoders] Re: Cairngorm Responder interface > changes > > > > On Thursday 06 July 2006 14:49, JesterXL wrote: > > > Just what I need, 10 billion more state variables to keep > > track of... > > > > Point taken, but they don't all have to be flat i.e. direct > > properties of the model. > > You can have model.viewHelpers.* , model.thingsAboutFoo.* etc. > > > > -- > > Tom Chiverton > > > > **************************************************** > > > > This email is sent for and on behalf of Halliwells LLP. > > > > Halliwells LLP is a limited liability partnership registered > > in England and Wales under registered number OC307980 whose > > registered office address is at St James's Court Brown Street > > Manchester M2 2JF. A list of members is available for > > inspection at the registered office. Any reference to a > > partner in relation to Halliwells LLP means a member of > > Halliwells LLP. Regulated by the Law Society. > > > > CONFIDENTIALITY > > > > This email is intended only for the use of the addressee > > named above and may be confidential or legally privileged. > > If you are not the addressee you must not read it and must > > not use any information contained in nor copy it nor inform > > any person other than Halliwells LLP or the addressee of its > > existence or contents. If you have received this email in > > error please delete it and notify Halliwells LLP IT > > Department on 0870 365 8008. > > > > For more information about Halliwells LLP visit > www.halliwells.com. > > > > > > > > ------------------------ Yahoo! Groups Sponsor > > --------------------~--> See what's inside the new Yahoo! > > Groups email. > > http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/nhFolB/TM > <http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/nhFolB/TM> > > ---------------------------------------------------------- > > ------~-> > > > > -- > > 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%40yahoogroups.com > <http://www.mail-archive.com/flexcoders%40yahoogroups.com> > > Yahoo! Groups Links > > > > > > > > > > > > > > > > -- > 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%40yahoogroups.com > <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 ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/nhFolB/TM --------------------------------------------------------------------~-> -- 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/
