Last time we looked at Cairngorm's business delegates and services, and now we're going to see where Cairngorm commands fit in.

Cairngorm commands implement the ICommand interface, which specifies an execute method. The command may also implement IResponder, which specifies a result and a fault method, to be called on result or fault from the service, as the case may be. Each command is registered with a controller, with the FrontController delegating the work to the controller (the Service-to-Worker pattern). Figure 19 shows the location of all the commands and controllers.

Figure 19. The locations of the commands and controllers

Table 11 and Table 12 list each command, how it does what it does, and what type of service is involved.

Let’s look at the commands that call the methods we already looked at on the bookie delegate. First is the command to sign a user into the system, SignInCommand:

package lcds.examples.bookie.command {
 ...
     public class SignInCommand implements ICommand, IResponder {
  
           private var model:BookieModel = BookieModel.getInstance();
  
           public function execute(event:CairngormEvent):void {
                 var evt:SignInEvent = event as SignInEvent;
                 var delegate:BookieDelegate = new BookieDelegate(this);
                 delegate.findPersonByCardNumber(evt.cardNumber);
            }
  ...

Note that SignInCommand implements both ICommand and IResponder, which means that we expect this command to call a service asynchronously and get a call back to result or fault when the service is done. Asynchronously simply means that there’s no way for the Flash Player to call out to Java and wait until it’s done before going on with execution. You don’t even really want it to. Because Flash isn’t multithreaded, all execution in the Flash Player would be on hold until Java came back with an answer. When we call a method on a remote service we always specify a “callback,” or a method to call when it’s done. The Flash Player keeps track of that for you, but once you call out to the service layer, execution continues from the point you make the call and the method that’s making the call ends. In this case, the callbacks are those result and fault methods specified by the IResponder interface.

Here are the implementations in the SignInCommand:

public function result(result:Object):void {
     if (result.result != null) {
           var p:Person = Person(result.result);
           model.user = p;
           model.loginFailedMessage = "";
  
           model.currentState = BookieModel.SIGNED_IN;
      } else {
           model.loginFailedMessage = "That card number was not found";
      }
     
}

public function fault(fault:Object):void {
     Alert.show("Unable to sign in", "Error while signing in");
}

The result method gets called back with a result object. On the result object is a property called result which contains the data from the callback. If you look all the way back through the delegate to the BookSearchService in Java, and further to the DAO, you’ll see that this call will return a Person object, which should be the user matched by the card number. If that person isn’t null, we know we matched a user with the card number, so we’ll let the user sign in (pretty secure, huh?). We’ll see how the login process works in more detail in a bit; this is just to let you see that the command gets a call back to result when a service call originating in execute returns. The fault method just pops up a simple alert to say there was a problem, but of course, that could be more complex as needed.

Let’s look at a command that calls a data service, GetAllSubjectsCommand:

package lcds.examples.bookie.command {
 ...
     public class GetAllSubjectsCommand implements ICommand {
  
           private var model:BookieModel = BookieModel.getInstance();
  
           public function execute(event:CairngormEvent):void {
                 var delegate:BookieDelegate = new BookieDelegate();
                 delegate.getAllSubjects(model.subjects);
            }
  
      }
}

Get your copy of Tony Hillerson's Enterprise Application Development with Flex.

The GetAllSubjectsCommand only implements ICommand, so it doesn’t expect to be called back by the service after its execution is complete. And look at how simple the execution is too; all it needs to do is get the reference to the subject collection from the model and pass it to the delegate, which you’ll remember calls a fill on that collection.

The Command pattern is a smart way to keep execution of a discrete set of functionality modular and reusable. Anyplace in the code that needs to get all the subjects doesn’t need to know anything but to call the right command, and that command can be called anywhere in the application. If the process to get all the subjects into a collection changes none of the code that kicks off the command needs to know, so they’re insulated from change.

Next week we'll look at the Cairngorm model locator and how we'll use the power of Flex's binding to easily configure the view based on the state of the model. You can always find the entire series here.