part4

User Gestures have Changed

Applications have grown in complexity these days and there are many different ways that the user will need to interact with your application. Every opportunity that a user has to interact with your applications is a gesture. In the traditional HTML interface world, each gesture requires the loading of a new page. AJAX has changed this somewhat, and Flex has changed it a lot. Sorting a data grid or filtering a group of data can all be done without a round trip to the server? This is part of what leads to a rich experience for the user. A benefit of Cairngorm is that all gestures, whether or not a round trip to the server is needed, can be treated exactly the same. No matter what is going on, we have a standard set approach, and can use that to more easily debug potential problems.

Events, Commands, Controllers, oh my

First, we create a CairngormEvent class for each user gesture. The event class extends a CairngormEvent. It will contain a static variable with the name of the event. It can also contain instance variables, if those are needed to complete the event actions. This might be a sample CairngormEvent class:

package com.tempApp.event{
import flash.events.Event;
import com.adobe.cairngorm.control.CairngormEvent;

public class MyCustomEvent extends CairngormEvent{
public static var EVENT_ACTION : String = “actionname”

[Instance data here]

public function MyCustomEvent ([Instance data as arguments]){
[Set Instance Data Here]
super(EVENT_ACTION);
}

/**
* Override the inherited clone() method, but don’t return any state.
*/
override public function clone() : Event{
return new MyCustomEvent ( );
}
}
}

This is a simple sample event class, but very powerful. The event class ties into a command class is the one that does the work. A command is a pattern which always has a single point of entry: an execute method. By creating a generic execute method on every command, the Cairngorm framework can generically run any command in response to an event. This might be a sample command class:

package com.tempApp.command{

import com.adobe.cairngorm.control.CairngormEvent;
import com.adobe.cairngorm.commands.ICommand;
import com.tempApp.event. MyCustomEvent

public class MyCustomCommand implements ICommand{

public function execute(event:CairngormEvent):void{
var e : MyCustomEvent = event as MyCustomEvent;
[Do stuff here]

}
}
}

When Cairngorm “sees” the Event, how does it know to relate it to a command class? A third class, a front controller, ties the two together:

package com.tempApp.control{
import com.adobe.cairngorm.control.FrontController;
import com.tempApp.event.*;
import com.tempApp.command.*;

public class AssemblerController extends FrontController{

public function AssemblerController(){
initialiseCommands();
}

public function initialiseCommands() : void{
addCommand(MyCustomEvent. EVENT_ACTION, MyCustomCommand );
}
}
}

I had one of those “hallway conversations” with some folks at 360Flex and a few people claim that a front controller has no place in a Cairngorm and is just overkill. I haven’t had time to think about that, or look into alternatives to the approach, but I thought it’d be something worth throwing out there for those listening. If you have thoughts on this, comment and tell me why a controller has no place in Cairngorm.

Tying them all together

We have three elements at play, here:

  • Start with an event (AKA User Gesture).
  • The Event goes to a controller and figures out what command to execute.
  • Execute the Command

There are two missing bookends to our list list. First, what exactly does “Start with an event mean”? How do we tell the Cairngorm Framework or Flex that an event has taken place? Cairngorm has a special event dispatcher that tells the framework something happened that it needs to respond to. A sample line of code would be something like this:

import com.adobe.cairngorm.control.CairngormEventDispatcher;
import com.tempApp.event.MyCustomEvent;

CairngormEventDispatcher.getInstance().dispatchEvent( new MyCustomEvent ([optional arguments]) );

That is our first bookend. We dispatch our custom event, which looks at the controller, and executes the command. Holding up the stack, the command will then update the ModelLocator, which through the miracle of data binding will update relevant areas of the application. Our updated path list is like this:

  • Dispatch a custom event (AKA User Gesture).
  • The Event goes to a controller and figures out what command to execute.
  • Execute the Command
  • Command updates Model data, which updates the user views


Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: