how about an xsd to as3 class generator?

There are some really powerful solutions out there for communication between Flesh apps and the backend nowadays. LiveCycle Data Services, BlazeDS, Red5, GraniteDS, PyAMF, OpenAMF … and of course support for SOAP and JSON … and I’m sure there are others I’m forgetting. When I think about the bad old days of loadVariables(), we’ve come a long way.

However, not every project is worth the overhead of defining web services with a server side developer. Sometimes there is no backend. There’s just a crufty little more-or-less static XML file sent as-is, straight from the server’s filesystem via HTTP. Except maybe we will be editing the XML file later on by hand when the content changes, says the producer as an aside. OK?

In the real and dirty world of agency work, this is a pretty common scenario. In these cases, you load up the XML file, and nowadays we have some much better tools to read it in and deal with it, like E4X. All well and good. But it’s still patently unstable. You end up doing procedures that are very close to the structure of the data, very low-level, and therefore very much prone to fail in odd ways. Don’t get me wrong, I like E4X, but I don’t want casual references to tags and attributes that may or may not be there scattered through my code. The fact that FDT shows “warning” syntax underlines for E4X operations is, perhaps, a mistake on their part, but a telling one. If I refer to:

myXmlDoc.arbitraryTag.@someAttribute

… I am making a number of assumptions. I’m assuming there is an node “arbitraryTag” in my document, and it contains the attribute “someAttribute”. The deeper into the DOM you go, the more tenuous it gets, and the less likely we are to think of checking for exceptions. And, at the end of the day, why are we checking for exceptions? XML Schema represent complex data types, of which XML documents are instances.

Our XML Schema should map to static classes, not dynamic objects. Much as we use the ValueObject pattern in remoting and data services. Then we can guarantee that if someone edits the XML file, and it validates against the XML Schema, it will be able to be translated into an object, an instance of those classes. Right now, the way I’m dealing with XML reminds me of hacking Object.prototype : - (

What would be great - and if I get the time I will build one - is a system that will read in an XML schema - because it’s pretty easy to write a schema that defines what’s acceptable in the project-specific XML file and what isn’t - and generate me some ActionScript classes that encapsulate these rules. A bit like the way Flex Builder can read in WSDL and create ActionScript stubs. Except for XSD. Then we could have a translator engine that can create project-specific objects out of my XML documents (and, potentially, vice-versa).

There are such things in the Java and .NET worlds: JAXB (if you follow the link you’ll see a diagram that explains what I’m getting at, much better than I have), for instance, or CodeXS.

Why would this be good? Because errors in dealing with these kinds of objects would create compile-time errors, not run-time ones; and the XML Schema can then be a technology-neutral validation point for the documents that everything else feeds off. If it needs to change, I can then regenerate my classes from it, and it will be obvious what else I need to change in the app to deal with the change.