Cool, thanks man. Yeah, concerning the callbacks (2), just intrested to know success or failure (no data), so the view could react if necessary (applicable when binding is overkill, of course).
-TH --- In [email protected], "JesterXL" <[EMAIL PROTECTED]> wrote: > > Tim, as long as you don't go off and use AJAX, we'll all love you no matter > what you do. > > 1. Nope. The common use case is remoting calls, webservices 2nd, > httpservices 3rd. Everyeone will get ResultEvents & FaultEvents. Those who > don't are using custom stuff, and thus know what they are getting into. > > 2. Steven, and others like my boss the architect, do not like the > possibility of View's getting raw server data. For example, an unfettered / > un-processed result that comes back from a Delegate call could make it's way > back to the View the originaly fired the Command. This makes it all too > easy for developers not experienced with Cairngorm to allow View's to start > screwing with data. They also have to "know" about ResultEvents and > FaultEvents. To me, it's worth it; we just use the convention "if we get a > result, it succeeded" and follow the original rules. > > Regarding state, yeah man, you stated my feelings exactly. > > 3. Cool. > > I'm working on training online material, professional for a change, that > will have a lot of the above. The rest I'll blog as usual when it's > presentable. > > ----- Original Message ----- > From: "Tim Hoff" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Wednesday, July 05, 2006 2:51 AM > Subject: [flexcoders] Re: Cairngorm Responder interface changes > > > Hi Jesse, > > Let me start by saying that I acquiesce; no more viewHelpers. All > code has been rolled into the view. For component oriented > development, it makes sense. > > Concerning your cogent points of view: > > 1) ResultEvent & FaultEvent events: Not sure how much of an impact > this makes in reality, But yes, do we need to support "undefined"? > It adds weight. > > 2) Command callbacks: When I first got into Cairngorm, I wondered > why there wasn't a round trip of communication back to the > view/gesture. There are plenty of local view actions that benefit > from knowing the result of a command; maybe "ViewResponder". Here, > I would hope that you would accept Steven's invitation to show your > enhanced code, so that it might benefit all of us by possibly being > rolled into Cairngorm. > > Functions vs. state variables: Yes, the scope of the function > dictates the need for state representation. I mean, if model == > state, should every toggled RadioButton or focused TextInput require > a state variable for control. At a point it becomes redundant, and > more efficient to address locally. > > 3) Added 2 methods to ServiceLocator: See #2 about sharing and > possible adoption. > > My comments to you are not personal, or even professional. I have > seen your work, website, and sat in on one of your online > presentations. I think that you are brilliant. Being from SoCal, I > know and appreciate your snowboarder mentality. :) I agree with > your points here. I would just hope that, instead of bagging, you > would contribute your proposed solutions, so that we all might enjoy > a cleaner architecture. > > ::looking for teddy bears:: > -TH > > --- In [email protected], "JesterXL" <jesterxl@> wrote: > > > > Sending again; sent at like 10:00am this morning, but still don't > see it. 10:03pm now. > > > > ------------------------- > > > > 1. ResultEvent & FaultEvent events. I disagree with this change, > so have changed them back instead of of using the * change for the > Responder interface. > > > > 2. Command callbacks. Sometimes, there is a legitimate need for a > View to "know" when a Command is completed. In my consulting, we've > added an optional callback method that can be passed via > EventBroadcaster (Cairngorm 1). So, View's launching Commands have > the option of using a Callback (like flash.net.Responder) to have a > result method called when the Command is done. We extended > Cairngorm's command to have all of this plumbing hidden. The > convention we have is, "If the View has his onResult run, he can > conclude that the Command succeeded in it's operation." If a fault > was fired in the Delegate, this means the app is broken and needs to > be fixed. There is no error handling, only error fixing. > > > > In my personal work, I've implemented both; result and faults, via > Event's. If an event extends my JXLEvent class (which extends > Cairngorm), it has the option of getting those callbacks. I should > probably do it like we do it at work, but for now, it works. I like > handling errors, so although fault and result are pretty low level, > I can have View's handle errors (or Commands obviously). > > > > Both avoid ViewLocator via a nice convention. It also makes it > cake to have a chained command with visual feedback. You can have > your View fire off other commands in a particular order AND show > visual feedback the whole time. Could you do this by binding? > Sure, but I'd rather use functions vs. state variables. > > > > 3. Added 2 methods to ServiceLocator. He doesn't support Producer > or Consumer (MessageAgent) services, so with a new method he does. > He also doesn't support NetConnection; with the new method, he > does. Since Cairngorm was made for a more request response, it > feels like both of the above are halfway implemented, but for > sending messages, Cairngorm works great, including Acknowledge > messages for Delegates that fire the original message. In both > cases, actual callbacks are handled by totally different classes > that basically act as Observers, and emit events. The more > specialized (for example, a channel in FDS created for Text > messages, and thus Chat only) is an extension of that > ConsumerObserver class, called ChatObsever, and he omits Chat > specific events for those who care. They, like Delegate's, utlize > ServiceLocator. > > > > I would, however, prefer you all either give me a better idea(s), > christen this idea as good for handling NetConnection / FDS' > consumer/producer model, and/or implement something that supports > these push based technologies into Cairngorm. > > > > With the exclusion of #1, both #2, and #3 can be done via > extneding the Cairngorm base classes so you're not affecting the > original framework, only extending it. I'd prefer #3 be made > official though, by you all somehow, some way. > > > > ----- Original Message ----- > > From: Steven Webster > > To: [email protected] > > Sent: Monday, July 03, 2006 6:03 PM > > Subject: RE: [flexcoders] Re: Cairngorm Responder interface changes > > > > > > Jesse, > > > > I'd love for you to share the modifications you're making to > Cairngorm, and to understand the rationale behind these changes. > It's not our intention that developers would typically need to > change the framework locally, and doing so certainly makes it more > difficult for folks to follow us on any upgrade paths as time rolls > by. Different strokes for different folks though. > > > > But if you can share your motives for changes, and the changes > themselves, then we can consider rolling them into the framework if > they satisfy general concerns. > > > > 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:[EMAIL PROTECTED] On Behalf Of JesterXL > > Sent: 03 July 2006 20:13 > > To: [email protected] > > Subject: Re: [flexcoders] Re: Cairngorm Responder interface > changes > > > > > > Don't have Flex 2 open in front of me ( client hearts 1.5 ), but > you can I > > think do: > > > > public function onResult(event:* = null):void > > { > > ResultEvent(event).result > > // or... > > var yourEvent:ResultEvent = event as ResultEvent; > > } > > > > I can't remember if you can cast in the function signature as: > > > > public function onResult ( event:* as ResultEvent = null ) > > > > ...but, either way, you can also do what I do; keep your own > build of > > Cairngorm locally! I've yet to work on a project where the team > didn't > > modify their build of Cairngorm to suit their needs. > > > > ----- Original Message ----- > > From: "ben.clinkinbeard" <ben.clinkinbeard@> > > To: <[email protected]> > > Sent: Monday, July 03, 2006 3:00 PM > > Subject: [flexcoders] Re: Cairngorm Responder interface changes > > > > Ah ha. Actually, I had to change them to > > > > public function onResult(event:* = null):void > > public function onFault(event:* = null):void > > > > so that they matched the signature exactly. I guess my confusion > was > > in that I was viewing the :* as meaning the developer could > specify > > whatever type they wanted. I was seeing * as a kind of > superclass when > > that is in fact not the case. I have to agree with Jester; I > don't > > really see the point of this change. > > > > Thanks for your help, > > Ben > > > > --- In [email protected], "Clint Modien" <cmodien@> > wrote: > > > > > > you need to change these lines > > > > > > public function onResult(event:ResultEvent):void > > > public function onFault(event:FaultEvent):void > > > > > > to this... > > > > > > public function onResult(event:*):void > > > public function onFault(event:*)void > > > > > > On 7/3/06, ben.clinkinbeard <ben.clinkinbeard@> wrote: > > > > > > > > Can someone explain why it is telling me I've implemented the > > > > Responder methods with an incompatible signature? > > > > > > > > public function onResult(event:ResultEvent):void > > > > public function onFault(event:FaultEvent):void > > > > > > > > The signatures shown in the docs are > > > > > > > > public function onResult(event:* = null):void > > > > public function onFault(event:* = null):void > > > > > > > > What am I missing here? > > > > > > > > Thanks, > > > > Ben > > > > > > > > > > > > --- In [email protected] <flexcoders% > 40yahoogroups.com>, > > > > "der_kotty" <kotty.tm@> wrote: > > > > > > > > > > Hi, > > > > > > > > > > I was just wondering why the > com.adobe.cairngorm.business.Responder > > > > > interface has been changed since it has been released on > Adobe Labs. > > > > > In Cairngorm 2.0 alpha > (org.nevis.cairngorm.business.Responder) the > > > > > parameters of the onFault and onResult handlers were typed > events > > > > > (ResultEvent and FaultEvent). > > > > > > > > > > Why have the parameters been changed to '*'? Where is the > sense in > > > > > that? To my opinion this is not really best practice but > maybe > > > > > there's a really good reason for that? Does anyone know? > > > > > > > > > > Cheers > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > -- > > 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 > ------------------------ Yahoo! Groups Sponsor --------------------~--> See what's inside the new Yahoo! Groups email. http://us.click.yahoo.com/2pRQfA/bOaOAA/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/
