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.

In the past year or so I’ve been playing the role of technical lead / architect on most of the Flex projects I’ve been working on. Usually this involves a team of 3-6 developers and 1-3 designers. The focus of my blog over the next few months will be to pass on the tips and tricks that I’ve learned as a lead developer working with other developers and designers, the bosses as well; PMs, technical managers, QA managers, customers… et al.

To get started a few tips:

Use source control

At EffectiveUI we typically use SVN repositories, but choosing the right technology isn’t really as important as making the choice to use source control. Also, make sure your source control servers are redundant, or someday you might wish you had.

Create an easy designer developer workflow

In the world of RIAs the ability to stay agile within a life cycle of a project hinges on this point. If getting from design to an implementation of that design is anything less than nimble, you’ll feel some pain.

Patterns, paradigms, and frameworks… oh my

Select and use a micro-architecture that makes sense for your dev group and/or application. Cairngorm is one of the more popular micro-architectures used in Flex development, it’s what we use at EUI.

The benefit and problem with most Flex micro-architectures is: keeping the framework light weight and simple also means that (while providing flexibility) they do not provide enforceability. In some areas this is, arguably, a good thing and in others it’s not so good.

Needless to say, most of my posts will focus on Cairngorm and how we have used and tweaked it to create a good software design as well as an agile development environment.

Stay tuned for more….
-adam