With a list of the variables on the class, loop through and assign values to the class variables. Looping through the known classes lets us look into the Web Service object to see if the variable is there. If the variable exists, then the value is automatically transferred to the class. Because internal classes are static, an error is thrown if an attempt is made to set a variable that hasn't been written into the class at compile time.

if (translateFrom.hasOwnProperty(vName) && translateFrom[vName] != null) {
// in the example, translateFrom is the incoming Web Service object or untyped object - check the incoming untyped
object to see if it has the property being looked for.
// do something here
}

From here, it's a matter of checking the type to transfer the variable accordingly. I've found some variable types from Java don't transfer over correctly. For example, longs sometimes don't transfer over as simple numbers and Booleans don't transfer over to a simple Boolean value. Sometimes they transfer over as a complexString value type that contains an XML snippet from the SOAP packet that Flex received. In most cases, when using the value in a complexString, it matches correctly and the fact that the object isn't strictly the type needed is barely noticeable. However, in certain cases, the difference becomes very noticeable. I've found that fixing it at the source helps eliminate problems down the road.

case "Number" :
translateTo[vName] = new Number(translateFrom[vName]);
    // translateTo is the class that is being populated
break;

This object translator can be extended to work with an array of objects as well. Once the class is inspected, you can get the name of the class. This lets you create a reference to that class and thereby dynamically create new instances of that class:

var classRef:Class = Class(getDefinitionByName(className));

Then when looping through the array of class objects create a new class object to store the data for each object in the array. From the example code, arrayOfObjects is the incoming array, classinfo is the describeType xml:

if (arrayOfObjects != null) {
     for (i=0;i<arrayOfObjects.length;i++) {
       tempObj = new classRef();
     returnArray.push(translateObject(arrayOfObjects[i],tempObj,classInfo));
   }
}

Notice that most of the functions in the class are static functions:

public static function translateObject(translateFrom:Object,translateTo:
Object,classInfo:XML=null,upperCaseFromVar:Boolean=false):Object {

Making the class functions static means that they can be used without creating an instance of the class. Static functions aren't tied to any particular instance of the class, but to all instances of that class. In effect it becomes like any other utility class that Flex uses. An example of the difference between static functions and instance functions is best illustrated by the Date class. When using the date class to store date information an instance has to be created then functions are available to modify or get the information stored in that date object. For example:

    var myDate:Date = new Date;
    var myMonth:Number = myDate.getMonth;

The function getMonth is only available on an instance of the Date class. It uses information stored in that instance to return its value. The Date class also has a static function:

Date.parse()

The parse function is a static function available on the class itself, not on a particular instance. Likewise, once the object translator class is imported into the application file, any of its functions can be used from the class itself:

import comp.ebay.utils.ObectTranslator;

if (eventObj.result.HistoryTos != null )    {
dpHistory.source = ObjectTranslator.translateArrayObjects(eventObj.result.HistoryTos.source,HistoryTo);

}

This returns an array of objects. However, there are times when you have to translate a single object. The function, translateObject, returns a typed object under the guise of an untyped object. This is done so that any kind of class can be translated. If a type of class were typed for return on the translator object, it would only be able to translate that specific class (which would be of little value). Returning an untyped object allows for flexibility in what this function gets used for. Now casting the returned object as a specific class or transfer object will work because intrinsically it IS the internal transfer class that Flex knows about. For example:

var historyItem = HistoryTo(ObjectTranslator.translateObject(event.result,HistoryTo));

and

var historyItem = ObjectTranslator.translateObject(event.result,HistoryTo) as HistoryTo;

There's one additional benefit for ColdFusion users that can be gained from a generic object translator. Pre-ColdFusion 7.02 variable names are all uppercased when sent through Web Services. In the example objectTranslator class (see Listing 1) some quick code has been added that checks for uppercased variable names on incoming objects, moving them into the variable names of the correct case.

In summary, once all Web Service objects have been translated to internal classes, strong typing can be maintained by casting any Web Service objects to the transfer classes. If variable names on the transfer objects have to change (which they often do), it's a much smaller job to catch all of these problems at compile time than it is to debug and find them at runtime. In a language like Flex that's strongly typed, using transfer objects makes for more efficient use of time and energy. Problems can be caught sooner and with less impact to users. Using class introspection offers the ability to look into a class and see the properties and methods inside the class. Those properties can be used to fill transfer objects and eliminate much duplicate code.