Best Practices for MXML Development

The preceding discussion touches on best practices that Adobe Consulting urges developers to adopt when implementing their own user experiences with MXML.

One key best practice is "to develop with components in mind." With MXML, it is incredibly easy to create components that extend base tags with application-specific functionality. If you have ever had to review someone else's MXML code and tried to trace your way through hierarchies of VBox controls containing HBox controls containing VBox controls containing TileList controls containing VBox controls, and so forth, you will quickly realize the value in creating components that have semantic meaning.

If you review the Cairngorm Store's code, you will quickly be able to cross-reference MXML components with their visual renderings on the screen. By creating components such as Main, SideArea, ProductDetails, ShoppingCart, ProductDetails, ProductThumbnail, GraphicalProductList, TextualProductList, ProductAndCheckoutViewStack, and so forth, you will be able to navigate your own source code more easily, never mind someone else's code.

When designing with components in mind, learn to use the events infrastructure within Flex to couple your components loosely. For instance, create your own events, which describe what happens at the user level, not at the Flex framework level. Consider the difference between a button within a VBox control having some code within a click="" event handler, versus a component called ShoppingCart that responds to an event called productAdded. When you create your own events, broadcast these events from within your components and handle these events accordingly. Your code base will become much more maintainable.

Again, consider the ProductDetails component in the Cairngorm Store, which is an application-specific rendering of a Panel component that broadcasts an event whenever the user clicks the Add to Cart button:

<mx:Panel
              xmlns:mx="http://www.adobe.com/2006/mxml" 
              xmlns:details="com.adobe.cairngorm.samples.store.view.productdetails.*" 
              title="Product Details" 
              styleName="productDetails"> 
  
  <mx:Metadata>
              [Event(name="addProduct", type="com.adobe.cairngorm.samples.store.event.AddProductEvent")]
  </mx:Metadata>

  <mx:Script>
<![CDATA[
              import com.adobe.cairngorm.samples.store.vo.ProductVO;
        import com.adobe.cairngorm.samples.store.event.AddProductEvent; 
        
        public function addProductToShoppingCart() : void
              {
              var event:AddProductEvent = new AddProductEvent();
              event.product = selectedItem;
              event.quantity = numericStepperComp.value;
              dispatchEvent( event );
              } 
              : : :
  <mx:Button
              label="Add to Cart"
              click="addProductToShoppingCart();" />
  </mx:Panel>

Here the click event of the button generates an addProduct event out of the component. Furthermore, the event includes the selectedItem (the product to add) and the quantity attribute associated with it on the ProductDetails component, which represents how much of the product the user wishes to add to the shopping cart.

Although this advice is in no way specific to Cairngorm application development, following these best practices for MXML development improves the clarity of your application code and makes it easier for you to recognize integration points between your MXML and ActionScript implementations of the view, as well as with any underlying business logic applied throughout the Cairngorm skeleton.

Where to Go from Here

When developing an enterprise RIA, it is important to understand how to construct a view using the building blocks of MXML and ActionScript. Equally important is understanding how you can build this view on the underlying architecture of the Cairngorm skeleton.

In this series of articles, you have seen how to manage client-side state using the Model Locator and Value Object patterns. Although we've given some guidance and best practices to consider when architecting your view, Cairngorm makes no assumptions and imposes no restrictions on how you choose to architect your view.

Now that you have a better idea of how to implement the view and keep state on the view, it is time to look at how to implement features with the addition of business logic within commands—the "application" in rich Internet application. We cover that topic in Part 4.

Developing Flex RIAs with Cairngorm microarchitecture – Part 4: Feature-Driven Development

Page 4 of 4

Previous Page