I just have to say I don't want Steven or Aral's job. Making & maintaing frameworks is f'ing hard, and I'm glad I get the luxury of proposing ideas without too much thought given to the potential consequences to the greater developer community whereas he does. The fact that he is passionate about ensuring success, and yet open to ideas is pimp!
----- Original Message ----- From: "Tim Hoff" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, July 11, 2006 1:12 PM Subject: [flexcoders] Re: Cairngorm Responder interface changes Great, The migration issue is exactly why I don't wan't to have to hack this. My thoughts are for the development community at large. As a developer, the time that is required to devise or learn someone else's hack is much better served adding features. In looking at the framework, it's outstanding in every area. I believe that adding an event bridge back to the view will add to Cairngorm's flexibility. The beauty is, that if that you don't want to use the bridge, you don't have to. Developers can continue to maintain Local State and Shared State in the ModelLocator if desired. No worries. Or, they can choose to clean-up the ModelLocator by eliminating Local State variables altogether. This seems simple enough, without making radical changes to the framework. There are also several other proposed changes on this thread, that many agree should merit consideration. If these issues were just MY foresight or opinions, I would not have continued. But when several credible sources agree that something could be better, there's nothing wrong with a little proactivity. I'm so happy that people are sharing their passion for Flex and Cairngorm here. By participating, this forum is giving all of us the opportunity to jump ahead of the curve. Jesse, or anyone, if you have anything to add, please chime-in. This is my last bid for this issue. Steven, I'm sure, as always, that you will thoughtfully take everything discussed into consideration. I look forward to your blog opinions. Best Wishes, Tim Hoff --- In [email protected], "Steven Webster" <[EMAIL PROTECTED]> wrote: > > Guys, > > If I'm strangely quiet on this, it's because I plan on blogging some thoughts rather than piece-meal response to emails here. For what it's worth, I think there is "no right answer", this will ultimately come down not to best-practice, but personal preference. There are some things that strike me as "bad code smells", and I'll call 'em out if I see them. > > However, the only thought I'll throw in again - being agile boy again - is that I'd err on the simplest solution that works, and introduce complexity (and ultimately refactor the framework itself) only once I'm actually in there suffering the pain of the problem, not having foresight of the problem as he sees it. Jimmy G is being modest when he says he hasn't built big apps ... he's been building some pretty typical RIA with Flex for quite some time, if what he showed me in New Orleans at MAX2004 is anything to go by. > > I think we have to be careful when we start making changes to Cairngorm, and at least ask ourselves the question "is this useful to me, or useful to all applications built upon Cairngorm". The former, or somewhere in-between is the norm, the latter is the only time I would be comfortable changing (rather than extending the classes of) the framework. Bear in mind as soon as you work from your own modified Cairngorm classes, you're going to find it difficult to migrate with us. > > 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 Tim Hoff > Sent: 11 July 2006 14:35 > To: [email protected] > Subject: [flexcoders] Re: Cairngorm Responder interface changes > > > > Oh, please don't get me wrong, you're solution is great. It really > got me thinking in a different direction. I'm just trying to come > up with a standardized way to solve this need, that will generically > work for the majority of use-cases. I don't think that the > Cairngorm guys would consider any change unless it feels concrete > and scales easily. I sincerely appreciate your feedback Dimitrios. > Please know that there is no disrespect intended. > > Tim Hoff > > --- In [email protected] <mailto:flexcoders% 40yahoogroups.com> , "Dimitrios Gianninas" > <dimitrios.gianninas@> wrote: > > > > Ok, obviously I haven't built big enough apps yet to run into the > problems you and Jesse have. I've had to do something like that in > one app actually where I had multiple instances of the same window > created, I would send a ref of the view to the command so it would > know which window instance to update afterwards. > > > > Dimitrios Gianninas > > RIA Developer > > Optimal Payments Inc. > > > > > > ________________________________ > > > > From: [email protected] <mailto:flexcoders% 40yahoogroups.com> > [mailto:[email protected] <mailto:flexcoders% 40yahoogroups.com> ] On Behalf Of Tim Hoff > > Sent: Tuesday, July 11, 2006 2:06 AM > > To: [email protected] <mailto:flexcoders% 40yahoogroups.com> > > Subject: [flexcoders] Re: Cairngorm Responder interface changes > > > > > > > > Thanks Dimitrios, > > > > I like the more direct approach, but I don't think that this would > be the most effective way to handle asynchronous events. What I'm > considering is extending the Responder all the way back to the View, > through the FrontController. They are, after all, where the > CairngormEvent originated and was sent first. The FrontController > has a reference to the Command, so it could accept a responder. The > Responder to the view would have to be created. > > > > Pros: > > > > The permanent stop at the Command from a Delegate wouldn't be > removed, but rather used to condition the response back to the > view. Everything else works the same in the Command. All re- usable > data is dropped-off at the ModelLocator. The command then > conditions a response that includes the state of the call result. > Things like size, number of Objects, format, or anything that the > developer wanted to know, would be added to the Responder and sent > on its way. Rather, the event would be modified. Back at the View, > local state would be adjusted accordingly when the CairngormEvent is > completed. > > > > Cons: > > > > A race condition may occur with the ModelLocator binding to the > view's state and the local update of state from the View itself. > Also, a reference to the original CairngormEvent would need to be > maintained by the View and the FrontController. This would possibly > add weight. Less than the Command, Delegate, and Service, but > weight just the same. Would also add script to all views that care > about a response. > > > > I think that this approach has a more standardized feel. Does this > sound like a viable idea, that doesn't stray significantly from > Cairngorm? > > > > -TH > > > > --- In [email protected] <mailto:flexcoders% 40yahoogroups.com> , "JesterXL" <jesterxl@> wrote: > > > > > > Dude... do you know how many "results" we have in our app? > > > > > > I agree, this'll work for small Flash projects, but not for > Enterprise Flex > > > apps. You can't just start willy nilly throwing small state vars > on > > > ModelLocator for things like this; it'd get out of control, > pretty quick. > > > Granted, you can easily sanction it off in a new StateVars > specific class, > > > but then you have to keep track of updating those variables in > your > > > commands... no thanks, I'd rather have it baked in. > > > > > > ----- Original Message ----- > > > From: "Dimitrios Gianninas" dimitrios.gianninas@ > > > To: [email protected] <mailto:flexcoders% 40yahoogroups.com> > > > Sent: Monday, July 10, 2006 11:53 PM > > > Subject: RE: [flexcoders] Re: Cairngorm Responder interface > changes > > > > > > > > > > > > Good points, but I think that it can be handled in the following > fashion. > > > > > > The SearchView is an MXML component and it has a property called > results, so > > > its declaration would look something like this: > > > > > > <dg:SearchView id="theSearch" results="{ModelLocator.results}" /> > > > > > > So once your results return, they will trigger the call to the > setter method > > > of the results property, so in that setter, you can do those > little things: > > > > > > ... > > > public function set results( values:ArrayCollection ):void { > > > dg.dataProvider = values; > > > // do other little things here > > > } > > > ... > > > > > > That pretty much aught to solve your problem and you don't have > to write any > > > extra code. I think the important thing to remember is to create > small > > > components that will receive data via binding and set themselves > in a proper > > > state (meaning changing values on certain controls, etc...). > That way its > > > clean and reusable in some cases. > > > > > > Dimitrios "Jimmy" Gianninas > > > Optimal Payments Inc. > > > > > > -----Original Message----- > > > From: [email protected] <mailto:flexcoders% 40yahoogroups.com> on behalf of JesterXL > > > Sent: Mon 7/10/2006 9:41 PM > > > To: [email protected] <mailto:flexcoders% 40yahoogroups.com> > > > Subject: Re: [flexcoders] Re: Cairngorm Responder interface > changes > > > > > > ...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" TimHoff@ > > > To: [email protected] <mailto:flexcoders% 40yahoogroups.com> > > > 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] <mailto:flexcoders% 40yahoogroups.com> , "Steven Webster" swebster@ > > > 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 > > > > swebster@ > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: [email protected] <mailto:flexcoders% 40yahoogroups.com> > > > > [mailto:[email protected] <mailto:flexcoders% 40yahoogroups.com> ] On Behalf Of JesterXL > > > > Sent: 06 July 2006 21:11 > > > > To: [email protected] <mailto:flexcoders% 40yahoogroups.com> > > > > 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" swebster@ > > > > <mailto:swebster%40adobe.com> > > > > > To: [email protected] <mailto:flexcoders% 40yahoogroups.com> > > > > <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 > > > > swebster@ <mailto:swebster%40adobe.com> > > > > > > > > > -----Original Message----- > > > > > From: [email protected] <mailto:flexcoders% 40yahoogroups.com> > > > > <mailto:flexcoders%40yahoogroups.com> > > > > > [mailto:[email protected] <mailto:flexcoders%40yahoogroups.com> > > > > <mailto:flexcoders%40yahoogroups.com> ] On Behalf Of Tom > Chiverton > > > > > Sent: 06 July 2006 16:01 > > > > > To: [email protected] <mailto:flexcoders% 40yahoogroups.com> > > > > <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> > > > > <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> > > > > > <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> > > > > <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> > > > > > <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> > > > > <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% <http://www.mail-archive.com/flexcoders%> > 40yahoogroups.com > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > -- > > > WARNING > > > ------- > > > This electronic message and its attachments may contain > confidential, > > > proprietary or legally privileged information, which is solely > for the use > > > of the intended recipient. No privilege or other rights are > waived by any > > > unintended transmission or unauthorized retransmission of this > message. If > > > you are not the intended recipient of this message, or if you > have received > > > it in error, you should immediately stop reading this message > and delete it > > > and all attachments from your system. The reading, distribution, > copying or > > > other use of this message or its attachments by unintended > recipients is > > > unauthorized and may be unlawful. If you have received this e- > mail in > > > error, please notify the sender. > > > > > > AVIS IMPORTANT > > > -------------- > > > Ce message électronique et ses pièces jointes peuvent contenir > des > > > renseignements confidentiels, exclusifs ou légalement > privilégiés destinés > > > au seul usage du destinataire visé. L'expéditeur original ne > renonce à > > > aucun privilège ou à aucun autre droit si le présent message a > été transmis > > > involontairement ou s'il est retransmis sans son autorisation. > Si vous > > > n'êtes pas le destinataire visé du présent message ou si vous > l'avez reçu > > > par erreur, veuillez cesser immédiatement de le lire et le > supprimer, ainsi > > > que toutes ses pièces jointes, de votre système. La lecture, la > > > distribution, la copie ou tout autre usage du présent message ou > de ses > > > pièces jointes par des personnes autres que le destinataire visé > ne sont pas > > > autorisés et pourraient être illégaux. Si vous avez reçu ce > courrier > > > électronique par erreur, veuillez en aviser l'expéditeur. > > > > > > > > > > > > > > > -- > > > 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 -- 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/
