Service to Worker: broadcasting Cairngorm events

The final step involves broadcasting the events to which the controller responds.

Cairngorm events can be distinguished from events raised by the underlying Flex framework, by extending the CairngormEvent class. When registering an event in the Front Controller, it is expected that only Cairngorm events are registered.

Earlier versions of Cairngorm featured a singleton EventBroadcaster class (CairngormEventDispatcher) that collaborated with the Front Controller class. In the current version, this mechanism has been replaced with self-dispatching events. Each Cairngorm Event class has a dispatch() method allowing a new instance of an event to be created and dispatched via the EventBroadcaster. The following code is an example of dispatching a Cairngorm Event:

new GetProductsEvent().dispatch();

Consider how a user might perform a user gesture to add products to a shopping cart. The user could click the Add to Cart button on a product details screen or drag a product image to the cart. The application needs to translate each of these user gestures into a Cairngorm Event encapsulating the event information. So on the product details view component, a drag and drop action calls a helper method used to broadcast the event:

public function doDragDrop( event : DragEvent ) : void 
{                      
        var item : Object = event.dragSource.dataForFormat( "item" );
        ...
        addProductToShoppingCart( ProductVO( item ) );
        ...
}
 
public function addProductToShoppingCart( product : ProductVO ) : void 
{
        var quantity:Number = 1;
        new UpdateShoppingCartEvent( product, quantity ).dispatch();
}
 
...
 
<mx:DataGrid
        id="dataGridComp"
        dataProvider="{ shoppingCart.elements }"
        width="100%" height="100%" 
        dragEnter="doDragEnter( event )"
        dragExit="doDragExit( event )"
        dragDrop="doDragDrop( event )"
        dragOver="doDragOver( event )">
        
        ...
        
</mx:DataGrid>

This is an example of another best practice Adobe Consulting recommends: Provide simple methods that describe the broadcasting of an event in business terms. With those few lines of code, you can now entrust Cairngorm to ensure that AddProductToShoppingCartCommand is invoked, doing all the work necessary to update the client-side model through ShopModelLocator, which will also result in the ShoppingCart view (which binds to the ShoppingCart model in ShopModelLocator) updating to show the new state of the shopping cart.

Putting it all together, you can see how the Service to Worker microarchitecture (including the Front Controller, Event Broadcaster, and Command patterns) collaborates with the Model Locator and Value Object patterns to handle an entire conversation between the user and the rich Internet application.

Where to go from here

Through Parts 2, 3, and 4 of this series you've seen much of the Cairngorm framework. Regardless of how you choose to build rich and immersive user interfaces using MXML and ActionScript, Cairngorm plays an important role in listening to the user's interaction with these experiences, translating these interactions into an understanding of what the user expects, and executing work on the user's behalf.

Cairngorm helps to achieve this goal with a clean collaboration of design patterns: Front Controller, Event Broadcaster, and Command. These patterns form a tight microarchitecture called Service to Worker.

Every time you add a feature to the application, do so by creating a specific Command pattern, such as AddProductToShoppingCartCommand. This command performs the work associated with the user gesture or system event that caused the command to execute. For Cairngorm to execute this command, you use the addCommand() method in FrontController to register each Command pattern with an appropriate event name. Furthermore, it pays to follow a best practice of identifying your events as static constants so that you can benefit from compile-time checking of your event broadcasts, rather than trying to debug silent runtime failures when you mistype event names.

We've shown how Cairngorm provides a base class for your Front Controller patterns and an interface for your Command patterns. If you extend and implement these classes, you can broadcast self-dispatching Cairngorm Events from anywhere in your application to translate user gestures or system-level events into events that cause Cairngorm to pass control to the appropriate Command pattern.

This initial foray into application development may cause you to pause and reflect on the flow of control between different parts of the application architecture. As you become comfortable with this flow, however, you and your team will approach the addition of each and every feature to a Cairngorm application in the same way. In short, you will add an event to the controller, register it with a Command class, and implement the Command class to do all the work. With this approach you can drive the development of your application with feature after feature, in a consistent, predictable manner that scales well. With Cairngorm, your business logic is no longer scattered across an ever-growing ecosystem of MXML components. Gone, too, are the monolithic classes that state "if the application just did this, then do that; but if it did this, then do the next thing..."

The scalability of design, maintainability of the code base, and the simple, consistent approach to delivering new features into the application highlight the major benefits of using the Cairngorm microarchitecture.

For the rich part of rich Internet application, we've shown how to implement the view and how to keep state on the view. For the application part of rich Internet application, we've shown how to implement features with the addition of business logic encapsulated in commands.

In Part 5, we'll discuss the Internet in rich Internet application. You'll learn how to complement the richness of the user experience with the ability to reach out and invoke business logic that exists on a server—whether it's your own application server or third-party services exposed on third-party servers. With this final piece of the puzzle, you'll have everything you need to know to design, architect, and deliver your own highly complex enterprise rich Internet applications.

Developing Flex RIAs with Cairngorm Microarchitecture – Part 5: Server-Side Integration

Page 6 of 6

Previous Page