Developing Flex RIAs with Cairngorm microarchitecture – Part 2: Keeping State on the client

Binding the model and view together

One of the primary reasons you want data in the presentation tier of an n-tier application is to display that data. Furthermore, the R in RIA is about presenting data in a rich and immersive way.

To facilitate the display of data in an RIA, the Flex application framework provides a powerful feature known as data binding. Data binding allows one object in a pair of objects to act as a source and the other a destination. Changes to the source object are reflected immediately in the destination object. When the destination object is a visual component and the source object is client-side data, you suddenly have a powerful means for ensuring that changes to the client-side state are rendered to the user in real time. The user's view is never stale; the model (the client-side state) is always notified by the view (the user interface) if you have used data binding to bind the model and view together.

At Adobe Consulting, we have seen development teams produce convoluted solutions for updating the user interface whenever the underlying model changed. These teams became tangled in a mess pretty quickly when displaying data in different parts of the view in different ways. Consider the case in which you have a series of numbers that have been updated on a server. Depending on a user's location in the application, this may cause their table or graph display to update or it may update data in a dashboard summary about key assumptions for a business. Data Binding in Flex makes an easy job of an otherwise lengthy task that would require manual handling. By refactoring architecture towards keeping the data in a client-side model, and leveraging data binding between this model and the different view components, you eliminate much of the complexity around this kind of interactivity and responsiveness in an RIA.

Furthermore, we found that each developer kept the client-side state he needed for his application development tasks in his part of the code base. Consequently, when another developer needed to use that data in another part of the application, she had to create convoluted and complex solutions to ensure the data was visible from more than one place.

Often we found that developers referenced other data with long chains of component references, such as mx.core.Application.application.storeView.textualList.productGrid. Such strategies are incredibly brittle and difficult to change. For example, adding or removing any components from this list (such as storeView) would require a developer to update all other references to productGrid.

Additional strategies include passing data up and down through MXML component instantiations. Consider the following representation of MXML components, where data is in a leaf node of the tree and is required in another developer's leaf node. The only solution is to find a common branching point for both leaf nodes and then, from that branching point, pass the data down through the component chain with component instantiations, as follows:

<myView:MyComponent data="{this.data}" />

Once again, this is a strategy that is very brittle, and changes in the implementation of the view are quite difficult. It leads to regular errors when developers incorrectly pass data down the chain somewhere, or when they change views, causing the data to not reach its intended destination. Debugging these errors is a laborious job of tracing the component paths to confirm that data has been correctly passed between components. It's a frustrating task and not recommended.

Page 6 of 7

Previous Page

Next Page