Re: [flexcoders] Re: Cairngorm Responder interface changes

[JesterXL]

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: flexcoders@yahoogroups.com 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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of JesterXL Sent: 03 July 2006 20:13 To: flexcoders@yahoogroups.com 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@gmail.com> To: <[EMAIL PROTECTED]ups.com> 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]ups.com, "Clint Modien" <[EMAIL PROTECTED]> 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]ups.com <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 SPONSORED LINKS Web site design development Computer software development Software design and development Macromedia flex Software development best practice YAHOO! GROUPS LINKS  Visit your group "flexcoders" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___