Cairngorm Responder Interface Change

Doing some re-factoring today in a Flex 1.5 project, and realized a lot of our Commands & Delegates we’re implementing the Cairngorm’s Responder interface, but using vanilla (plain) Objects for the onResult and onFault functions. While that is the correct implementation of the interface, if you are using Remoting in Flex (RemoteObject, or even WebService / HTTPService), then that is technically correct, but not entirely accurate. Result events actually get mx.rpc.ResultEvent instances, and fault events get mx.rpc.FaultEvent.

While doing:

function onResult ( event : Object )

function onFault ( event : Object )

…is ok, the correct way is to do:

function onResult ( event : mx.rpc.ResultEvent )

function onFault ( fault : mx.rpc.FaultEvent )

Doing this, however, will break the interface’s contract. What I did is fix the interface. Good news is, if your existing code base already uses event : Object, that’s ok; ResultEvent & FaultEvent extend Object, so compiler wise, you are technically fulfilling the interface’s contract.

This is corrected in Cairngorm 2, although, the example casting in the comments is incorrect. While casting actually works in ActionScript 3, because of some frikin’ geniuses at Netscape (sarcastic) decided to keep backwards compatibility in a language spec (ECMA Script), you should really cast via “something as Class” vs. “Class ( something )” since the most commonly used client / server datatype, Array, cannot be used this way.

Benefits of doing this in Flex 1.5 is using strict datatyping for ResultEvent and FaultEvent properties, and easier to port to Flex 2. If you don’t cast in Flex 2, it’ll cost you speed as the interpreter will have to downcast the result to ensure it’s truly an Object and do dynamic lookups of properties.

4 Replies to “Cairngorm Responder Interface Change”

  1. Hi Jesse,

    But what if you Business Delegate was calling something other than remoting that involved an asyncronous call requiring the Responder interface? Examples:

    – FES Messaging
    – FCS NetConnection.call
    – XML Socket, XMLSend, LoadVariables etc

    Cheers,
    Robin

  2. Robin makes a fair point … one of the things I never liked about the Command pattern implementations in J2EE microarchitectures, was how the Command was tied to the technology implementation – in the case of J2EE, Commands ‘knew’ about HTTPRequest and HTTPResponse, which never felt right.

    As you say, in Cairngorm 2.0 we’ve proposed (we’re open to suggestion here, it’s a beta, and your feedback is both invaluable and welcome) an alternative implementation.

    Does the approach in Cairngorm 2.0 work for you, Jesse ?

    Best,

    Steven

  3. Good point, Robin. I’ve used Flashcom once in ARP, but never used a Delegate for it since it was all NetConnectioncall’s… hrm. None of those would work, and the current interface would prevent (preclude?) you from using them.

    It should probably be actually cast to *, meaning, no type. While this is slower than Object, you never know what you are getting back, and this is the most flexible, and explitly written to be so.

  4. …actually, I take that back. It should be probably be rest parameters, meaning … args so you can pass an optional amount as well as none, and it should return void.

Comments are closed.