Darron Schall beschreibt in diesem Artikel, warum es besser ist, in den konkreten Cairngorm Command Klassen das mx.rpc.IResponder Interface des Flex 2 Frameworks anstelle des com.adobe.cairngorm.business.Responder Interfaces zu implementieren.

Der Hintergrund: ruft man in Flex 2 einen Service auf (HTTPService, RemoteObject, Data Service), so erhält man als Rückgabewert ein mx.rpc.AsyncToken Objekt. Diese Klasse bietet eine addResponder(responder:mx.rpc.IResponder) Schnittstelle, um Empfänger für result/fault Events zu registrieren (in etwa vergleichbat mit Event Listenern, die man allerdings direkt am Service registriert).

Implementiert man in seinen Commands das IResponder Interface, so hat man eine zum Flex Framework kompatible Lösung: Commands können so direkt als Responder zu einem AsyncToken hinzugefügt werden.

Außerdem ist der ursprüngliche Ansatz in Cairngorm etwas “gewöhnungsbedürftig”: hier wird dem AsyncToken die Eigenschaften resultHandler und faultHandler “angeflanscht”, die dann im result/event Handler auf der Service Klasse verarbeitet werden (z.B. result=”event.token.resultHandler(event)”). Dieses Konstrukt ist dann obsolet, da sich das Command bzw. sein Business Delegate selber um das AsyncToken und das Hinzufügen des IResponders kümmern.