Recently I worked on a project using Flex to create a front-end for Java-based Web Services. I ran into a favorite in the Java world: Transfer Objects/Value Objects. Early in the project, I was a bit skeptical of the transfer object model but, later on, I came to respect the value that it offers.

Transfer objects let two separate systems trade descriptive data objects without fear that either system will mistype the data or change the variable names. Transfer objects are an explicit agreement on how data will be encapsulated. They make integration easier because everyone can separate and build their system knowing what variable names and types will be traded. When someone modifies his version of the transfer object, the compile process should catch the changes and alert the file locations to fix the problems.

Flex automatically does the work of transferring a class type when using remote objects (one of the many reasons to use remote objects). However, when using SOAP Web Services, strong typing is broken because the class associations aren't automatically transferred to internal Flex classes. It's unfortunate, and leaves a bit of a gap when trying to use strong typing and compile-time error checking.

What's the value of strong typing? It makes it easier to debug the application. Instead of complaining at some obscure point when a user clicks on a certain button in the middle of a complicated workflow, it breaks during the compile process where the problem can be easily found and fixed. What could have been a two- hour search for a misnamed variable becomes a five-minute change.

The problem here though is how to get the untyped SOAP objects created by Flex into typed objects that Flex knows about - internal implementations of the transfer objects. The values themselves are typed, but there's no association between this data and the transfer object. Further, Flex can't be told that x SOAP object is actually of type y class. For example, trying to cast an incoming Web Service object into a user-defined TO class will cause a runtime error:

public var dpHistory:HistoryTo = event.result.HistoryTo as HistoryTo;

or

public var dpHistory:HistoryTo = HistoryTo(event.result.HistoryTo);

When I started trying to use strong typing of classes on the Flex side, I tried to do the transition by writing a custom transfer function for each type of class I had. For example:

var dpHistory:ArrayCollection = new ArrayCollection;
var tempObj:HistoryTo;
For (var i=0;i<webServiceReturn.result.HistoryTos.length; i++) {
tempObj = new HistoryTo;
tempobj.message = webServiceReturn.result.HistoryTos.getItemAt(i).message;
tempobj.objectName = webServiceReturn.result.HistoryTos.getItemAt(i).objectName;
.......
dpHistory.addItem(tempObj);
}

What a pain! It's error prone and doesn't allow for reuse. It's boring and adds to the amount of upkeep you have to do if anything changes. In the beginning, I avoided using transfer objects simply because that I didn't want to go through the pain of actually coding up every one of my Web Service returns like this. There are a lot of benefits to be gained by using transfer objects, but using the methodology above was horrible getting to them.

To me, the drawbacks (i.e., less code reuse, more duplicate coding, etc.) appeared to outweigh the benefits. Sure, these functions can be written up and saved as an ActionScript file somewhere and included when needed, but it looked like one transfer function was needed per transfer object. And that can be a real pain, especially in a large project with numerous transfer objects.

I figured there had to be a better way. After hunting around a bit, I came up with a solution that worked for my project. All that was needed was a generic object transfer utility to translate the incoming objects into typed classes that are created on the Flex side. Once the transfer objects have been written on the Flex side, then class introspection can be used to dynamically populate the values from untyped Web Service objects. Let me show you how I did it.

First off, create a transfer object class. One of the beautiful things about Flex is the automatic getters and setters for public variables on classes. This means that creating a transfer object can be very simple. Flex is flexible enough to use explicit getters and setters as public properties or to take public properties/variables and create automatic getters and setters for them. Creating custom transfer objects then becomes a breeze and literally takes just a few minutes to put together.

For example, a simple class might be a history display class:

package comp.myProject.to    {
public class HistoryTo {

       public var creationDate:Date = new Date;
       public var message:String = new String;
       public var objectName:String = new String;
       public var objectType:String = new String;

       public function HistoryTo() {
       }

    }
}

Once the custom class (transfer object) has been created on the Flex side, it can be used to store variables. Flex Builder knows about this class and can display hinting on the class names, warn when a property name has been misspelled, and make sure that the properties and values maintain their type across the application. The biggest challenge is filling the class with the proper information.

With a plain object or dynamic class, getting the dynamic values contained inside is done by looping through its properties (dynamic properties are values added to a dynamic class at runtime, like adding variables to a plain object). For example:

    for (item in myObject) {
       // do something here
       myVar = myObject[item];
}

Unfortunately, classes don't support this method for finding static properties. This is where class introspection comes to the rescue. Class introspection returns a listing of all static properties of a class and the types of those properties. Best of all, class introspection is actually very easy in Flex. For example, there's a function in Flex that returns an XML structure of all the class properties:

    import flash.utils.describeType;

var classInfo:XML = describeType(HistoryTo);

The function describeType returns an XML structure that can be looped over to get a listing of the public static properties, class methods, class name, and class base reference (if it extends a class). The function describeType won't return dynamic properties, private properties, or private functions. In the example, the classInfo variable now contains an XML object that can be looped through and/or treated like any other XML-type data source. For instance, it could output the results in a tree (a la the old object inspector for Flex 1.5). In this case, it can be used to loop through the Flex-side transfer classes, pull out the variables and types, check them against the Web Service objects, and transfer the Web Service object values to the appropriate class variables.

The root node contains the name of the class and the name of the class that it extends (if any):

var className:String = classInfo.@name;

To get the list of public variables on the class is relatively simple as well.

The classInfo..variable contains an array of variable names and variable types. Looping through them allows for assignment from one variable to the next:

var vName:String;
var vType:String;

for each (var v:XML in classInfo..variable) {
    // set the xml name and type options to strings for easy comparison
vName = v.@Name;
    vType = v.@Type;
//do something here
}