This is a set of posts documenting my experiences with utilising functionality within the Flex SDK that provides the automatic mapping of custom ActionScript classes to element definitions within an XML Schema (XSD).
1. Part 1 – Introduction and background
2. Part 2 – Overview of Flex’s XML Schema classes (inc example code)
Part 1 – Introduction and background
This post explains some reasons on why the automated mapping of ActionScript classes to XML Schema definitions can be a better alternative to other data integration options available to Flex (in certain circumstances).
Earlier in the year we were re-evaluating the various data formats available, in order to determine which options required the least amount of hand crafted serialisation for both the front end (Flex) and the backend (at Massive this is almost always .NET, however a significant proportion of our applications rely on 3rd party back ends utilising all manor of technologies).
We have utilised pretty much all data formats at some point or another (remoting with WebORB and Fluorine, JSON, SOAP and XML), they all have their pros and cons depending on the nature of project. Also, our .NET team generally prefer XML based REST API’s over SOAP/Remoting, as (among other things) these can be easily debugged in a browser, and are more easily cached (a factor that becomes significant when determining the scalability of large projects with high levels of data transfer). They also don’t tie the output from the server to a specific frontend solution (ie Flex/Flash) as is the case with remoting.
Flex provides functionality to automatically convert pretty much all the raw data types into primitive ActionScript objects, however apart from explicitly mapping ActionScript classes to server objects using remoting and [RemoteClass] none of the others support automated serialisation to and from custom ActionScript classes. So pretty much every data format requires some sort of manual serialisation (i.e custom code) to convert the data from the server into instances of specific classes (such as value objects – VOs) within the application.
Our aim was to determine if there was an existing solution that required minimal effort (code) on both the front end and back end that would facilitate automatic mapping of data between the server objects and ActionScript classes, and not limit the ability to cache common requests on the server.
It was about then that I stumbled across the suite of XML Schema classes available in Flex 3 in the mx.rpc.xml package. It allows you to encode/decode an XML document at run time using it’s referenced XML Schema (XSD). Not only does this automatically convert to and from primitive XSD elements (something the Flex SOAP classes also support – a good example being xsd:DateTime into a Date object), but more importantly, it allows you to register specific ActionScript class definitions against element definitions defined within the XSD using the following syntax:
This means that the content of any XML document that references a valid XSD schema can be automattically serialised into strongly typed ActionScript objects without any manual parsing/populating of the data.
If you look at the documentation for the mx.rpc.xml package you will only see a handful of classes that support simple XML encoding and decoding. This is because the majority of the classes relating to XML Schema contain [ExcludeClass] metadata that excludes them from documentation and code hinting.
At the time I did a few google searches on this topic that turned up nothing, which is surprising as this approach provides some of the key befits of remoting just by including XSD schema definitions along side an XML document/API.
In my next post I will run through the various classes in use, provide a simple example showing how they work and explain some of the cavets I have found.