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

Keeping an object model consistent between Flex and Java

Let’s now consider how to transfer the object model between the server and client. When you develop middleware, a key artifact from the development process is typically a well-defined object model. In J2EE application development, there is often a package of Java value objects already on the server that correspond exactly to the value objects required on the client.

In this case, the Flex server does some pretty significant heavy lifting for the application. If you want to pass ActionScript value objects into Java, Flex can automatically create the equivalent Java objects on the server side for those objects that you placed on the client side. Similarly, as the Java middleware returns Java value objects to the client, Flex ensures that by the time the RIA uses these objects on the client side, Flex has already translated them into the equivalent ActionScript value objects.

Even more powerfully, if the objects are not just single value objects but complex graphs of value objects, Flex does all the work associated with traversing the graph of objects—not only translating the objects but maintaining the relationships between objects. Thus, when you have a ShoppingCartVO that contains a list of ProductVO objects, and each ProductVO contains a list of AddressVO objects (for delivery and invoice addresses) and an optional DiscountVO object, Flex ensures that the composition of objects stays consistent when passing it between the RIA client and middleware server.

To allow Flex to map between client-side and server-side value objects, you must provide some hints to the server about the relationship between the classes. In Cairngorm, you achieve this by making certain that every instance of a value object class contains the following:

[RemoteClass(alias="com.adobe.cairngorm.samples.store.vo.ProductVO")]
public class ProductVO implements IValueObject

This line ensures that a ProductVO.as class on the client maps to the Java class ProductVO.java that resides in the package com.adobe.cairngorm.samples.store.vo on the server. Note the use of the IValueObject interface provided by Cairngorm; we encourage you to use this marker interface to identify your value objects.

ActionScript code generation

In a medium sized application containing a large number of VOs, it is easy to see why teams look for code generation techniques to reduce development time and cost. This approach can prove particularly useful when the number of value objects starts to escalate across multiple technology tiers. There are several well-known tools currently available that have proven successful at ActionScript code generation, including XDoclet2 and DAOFlex.

XDoclet2 is a Java-driven ActionScript code generator. Joe Berkovitz of Allurent created this labor-saving, open-source project for generating ActionScript value objects from their Java counterparts. You can find more information on the project, including a link to the source code on SourceForge, at http://xdoclet.codehaus.org/.

Another open-source tool that may meet your needs is DAOFlex, offered by Farata Systems. This utility can model a data access layer in ActionScript based on an SQL query. For more information and a tutorial on using this tool is available in the Adobe Developer Connection.

To recap, using value objects ensures that you do the following:

• Adhere to the best practice of representing client-side data with a meaningful object model
• Maintain a consistent object model on the client and server
• Leverage the capabilities of the Flex server to translate value objects between Java and ActionScript as they "cross the wire" between client and server

Getting data to the client that is consistent with the server is only the first part of the problem. The next part includes doing something with the data and deciding where to keep it.

Page 5 of 7

Previous Page

Next Page