As Flex developers we’re often inclined to use server-side technologies like Blaze DS, LiveCycle DS, ColdFusion, amfPHP, RubyAMF because of the native object transfer layers that these technologies have available. The magic in these solutions is a binary format called AMF (Action Messaging Format). AMF allows disparate languages to communicate with native objects. For example, in a Blaze DS Java server project if I define a class that has the same public properties as a class definition in ActionScript, Java and ActionScript can transport data of this type and deal with the data as a native object instance in each layer. The benefits gained from native object data transfer are: compile time type checking, speed, and elegance. However, this post is not about AMF, but about the pattern of translating other data formats (like XML, CSV, JSON) into the Flex application domain.

An important distinction when implementing a Flex application is the separation of domains. In a typical web application there are several domains to think about, but for the sake of this example let’s look at two: the service layer domain and the UI domain. The distinction between these domains is important to ensure high standards of maintainability and modularity. It is essential to avoid a situation where a change in the service layer has major impacts on the implementation of the UI layer, and vice versa. The Data Translator pattern is a simple pattern, but an important concept for keeping these concerns separated.

In this example I will be using XML translated to ActionScript VOs (value objects). XML is a common format in the world of web services, and especially in Flex development, however this pattern can be used with nearly any data format that a service might expose. That’s enough setup, now let’s dig in to the Data Translator.

A Data Translator is a class with static methods for parsing data generated by the service domain into a format that is specific to the UI domain. Data Translators are typically invoked by Delegate classes. In my opinion, the Delegate layer is the appropriate place to handle data translation. If your Command class is dealing with data that is part of the service domain, you may need to rethink your architecture. Like nearly everything in any field of engineering, there are exceptions to this rule. If you are implementing an application that’s function is to display read-only data, XML can be a great format for that application. However, if your application involves modifying data that was retrieved from a service, value objects are usually the best solution.

So, let’s check out the example application:

View the Application | View the Source | View the Docs 

DataTranslatorExampleApplication – Defines a button that dispatches the GetItemsEvent, a console to show Cairngorm actions, and a DataGrid to show the result of the operation.

ItemsCommand – Invokes the getItems operation on the delegate class and by standard Cairngorm convention, updates the global model with the items returned by the delegate.

DataTranslatorExampleDelegate – This delegate is responsible for calling the service that responds with a collection of items. The items are returned in an XML format and then parsed by the ExampleDataTranslator class.

ExampleDataTranslator – Translates the XML payload into a set of objects of type Item.

Item – A value object that models the data of an “Item”

This pattern is a favorite of mine for dealing with the translation of data into a format for the UI application domain.

Up next, tip #2 Aggregated Commands.