AS2.0 - XMLDocument class revisited…
July 8th, 2006
The XMLDocument class will help anyone who wants to save and load XML content and then handle it via a dot syntax object in Flash, there are a few deserialisers around, I wrote one myself a long while back (you can find it here.) but there's no solution I know of which wraps the whole process up in a neat little package... So that's the aim.
After thinking about the XMLDocument class (now called XMLSerialiserAlpha) a couple of things highlighted a new direction.
- The class should extend the XML class and wrap serialisation and de-serialisation.
- After looking at the problem of node attributes, 2 things came to mind.
- Properties named with a preceeding _ (underscore) could become attributes when serialising and vice versa for attribute names when deserialising.
- Properties could be placed in a container called __attributes.
- CDATA sections could probably be identified on the fly, any text value which contains CDATA chars can simply be written out as a CDATA section, this will slow down the processing so I may make this optional, and add a facility to specifically tag a property as CDATA.
As a result, the next version of XMLDocument will not be compatible with the previous version, which was only a basic class anyway.
To reflect this I've amended the old code and named the class XMLSerialiserAlpha, if you're using it, I'd suggest you update your code to follow suit, make a note of the usage instructions in the class comments.
I'll tackle implementing the new class(es) in the coming week, I'll work out the specification of the Object wrapper next, let's call it DataObject, and this will allow safe creation and wrapping of data objects (containing no methods or MovieClips.)
This provides a nice place to formalise the object structure for XML serialisation, and a standardised format to work with for data XML files.
can you Digg it?
is it del.icio.us? 
Category: General



3 Comments Add your own
1. robin | July 12th, 2006 at 3:49 pm
Hi Jason,
I’d be interested to see how this turns out - I’m just about to revamp my xml extending class that uses your original layer51 prototype (which you’ve seen in fact ;)).
Btw, Do you use the __resolve to return arrays as has been suggested on layer51?
2. diego | September 9th, 2007 at 11:05 pm
hello jason,
the layer proto function has never been implemented with the “always array”? i need this behavior, but i’m unable to modify your perfect scipt..
tks in advance
DIego
3. Jason Milkins | September 9th, 2007 at 11:51 pm
Hi Diego,
I’ve always maintained the original script shouldn’t do something which is inherently application specific.
If you always want a node to be recognised as an Array object, you should simply force it to be an Array if it didn’t happen to be one, in the case that your XML node didn’t have multiple entries.
There are a few ways to make the ALWAYS Array functionality happen, but it’s simply wrong to do it.
If you need to check if a parsed node is an Array you can perform a simple condition to convert it… eg.
myObjNode = (myObjNode.unshift == undefined) ? [myObjNode] : myObjNode;
I realise that many people want and want there to be a simple switch to pull on any tool to make it do something which is outside of it’s true scope. But to me it’s like wanting a gun that will only kill “baddies”.
My best advice is to add a method to your XML handling class (where I assume the Obj2Xml method has ended up (it’s where I usually find it) .. The additional method would be rightly called… forceArray (or something like that, and it should look something like the following code…
public function forceArray(obj):Array {
return (obj.unshift == undefined) ? [obj] : obj;
}
so whenever you need to work with a node on your parsed object (and ensure it’s an Array), you can just run forceArray(myNode) and then you’ll have your Array.
The only alternative is to start creating special attributes and or node names in your xml and specifically code the parser to recognise them as Arrays. This I don’t like, simply because the XML coming in shouldn’t adhere to any rules, it’s up to the Application itself to figure out what it wants to do with a node.
If AS2.0 was able to validate an XML against DTD or XSD then it would be a different story, also if (like with AS3 and E4X) it could differentiate attributes from nodes, it might not be so terrible to mark a node as an Array using a specific attribute name.
But as I say, there’s no way for XML to define a group of nodes as an Array (without DTD / XSD validation) so it’s counter to the design of the parser.
I hope my answer has been helpful, and clear.
Leave a Comment
You must be logged in to post a comment .
Trackback this post | Subscribe to the comments via RSS Feed