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" <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > > > > > > > > ------------------------------------------------------------------- ----------- > 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" <[EMAIL PROTECTED]> > 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 --------------------~--> 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/
