I thought it might be a good idea to set something of this nature up as web service, or a web application, using Google AppEngine. I found a Python system called generateDS that does pretty much exactly what I want, except it produces Python classes instead of AS3 ones. I got in touch with Dave Kuhlman, the author of generateDS; he pointed out that the system was written specifically for generation of Python code, not for producing other code in other languages. It should be refittable for AS3 but it would take quite a bit of deep hacking.

Another possibility would be to work from the XMLBeans codebase; but this is Java, and that would exclude the possibility of working with AppEngine.

I would just code it up in AS3 – possibly as an AIR app – but I hesitate to do so, because ideally this kind of tool should have a CLI, so that it can be used in build scripts.

Maybe I should write my own from scratch in Python or Ruby.

Hmm…

Share This

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.

Share This