Cairngorm is a lightweight micro-architecture framework for Rich Internet Applications built in Flex or AIR, defining best-practices for a RIA. Read More
When a Cairngorm command requires parameters to call the required delegate, a common (bad) practice is to fetch parameters from View Components / Calculate or Query from inside the Cairngorm Command, and end up writing complicated / un-understandable code inside Command files, when a Cairngorm event is being dispatched from > 1 AS files.
But isn’t all this going against the very purpose of using the Cairngorm architecture?
Why not have parameters passed to a Cairngorm Event every time its dispatched, and stay away from mixing C with M and V in a MVC Framework?
This post explains how you pass parameters to a Cairngorm command at runtime, via a Cairngorm Event.
Our data is held in a ‘data’ object of an Event and is used to ‘send’ parameters / data to a Command.
We start off by initializing the data object in the constructor of the event.
public function MyEvent():void
{
data = new Object();
}
Lets now ‘add’ data into this data object when a event is dispatched.
var event:MyEvent= new MyEvent();
event.data.myData1 = “Value1”;
event.data.myData2 = “Value2”;
event.dispatch();
Our parameters are also assigned everytime the event is dispatched, eliminating the need for parameters to be fetched in a Cairngorm Command. The Command class just needs to be modified a bit to read these parameters.
public function execute(event:CairngormEvent):void
{
var event:MyEvent = event as MyEvent;
var delegate:MyDelegate = new MyDelegate();
delegate.fn(event.myData1 , event.myData2);
}
Thus, each instance of the Command uses parameters given to the corresponding event, allowing the Command class to do what it does best.
We may again face issues, trying to obtain the result of the command in the class that dispatched the event.
Instead of going by the straight forward way of calling required methods (using Application.application / FlexGlobals.topLevelApplication) on obtaining a result in the Command Class, we can clean up our code a little more here by specifying the callback function for the resultEvent while dispatching the event.
We just need to declare another variable of type ‘Function’ in the Event Class to achieve this.
public class MyEvent extends CairngormEvent
{
static public var EVENT_ID:String=”customEvent”;
public var callbackFunction:Function;public function MyEvent()
{
super(EVENT_ID);
data = new Object();
callbackFunction = new Function();
}
}
Now this callbackFunction variable needs to be assigned with the value (read function) that needs to be called on the ResultEvent for the corresponding Command.
private function dispatchMyEvent():void
{
var event:MyEvent= new MyEvent();
event.data.myData1 = “Value1”;
event.data.myData2 = “Value2”;
event.callbackFunction = result_MyEvent;
event.dispatch();
}public function result_MyEvent(event:ResultEvent):void
{
// Read event.result
}
Finally, the Command class needs to make sure event.callbackFunction is taken into consideration while the Responder Object is being created.
public function execute(event:CairngormEvent):void
{
var event:MyEvent = event as MyEvent;var responder:Responder = new mx.rpc.Responder(event.callbackFunction, onFault_load); // Parameters : ResultEvent, FaultEvent
var delegate:MyDelegate = new MyDelegate();
delegate.fn(event.myData1 , event.myData2);
}private function onFault_load(event:FaultEvent):void
{
trace(event.message.toString());
}
Simple as that. The Command class is now free of all the complicated code that needs to be written for obtaining parameters.
‘Alerts’ in the resultEvent of the Command may also be removed now.. 🙂
— Update – 30/10/2010 —
Example :
Validate Email Address against the Mail Server
Desc : Demonstrates Interacting with a Command, through an Event while using a Cairngorm Framework. Connects with a SOAP webservice.
Feel free to post in any questions.
Leave a Reply