Introduction to XML in Flash
       by senocular

XML to XML Object
Immediately following the process of loading XML into Flash, there is a behind the scenes process which converts the original XML text into a usable ActionScript object that assumes the identity of what you know to be your XML instance. This process is called parsing. With a LoadVars urlencoded variable string, parsing converts the string into variables with their respective values. For XML, the parsing process creates a usable XML instance.

This sounds wonderful and easy at first, after all, you don't have to do anything yourself during this process. And making usable Flash objects out of the XML text? What's better than that? At second glance, however, and especially when you actually start working with this new ActionScript representation of XML, you start to realize that XML in ActionScript is far more complicated than it had previously seemed to be. Sure, conceptually, its easy enough to understand - elements, text nodes, CDATA; we've already covered that with no problem. However, once you take that and then shove it into an alternative programmatic structure (ActionScript), you have a whole new layer of complexity to deal with, and this especially when trying to code your way through that structure. XML alone may be easy. ActionScript alone may be easy. Put them together and it suddenly isn't looking so easy. Fear not; that's what I'm here for.

The trick to mastering your way through XML via ActionScript is through knowledge (whoda thunk?). Yes, as GI Joe has been telling us for years, "Knowing is half the battle." You will just need to know what in ActionScript represents what in XML and how to get to it so that you can retrieve what you need to retrieve (or perform whatever operation you need to perform). People are afraid of the dark because they don't know what dangers it may contain. People are afraid of XML because no one clearly explained to them what they need to know to fully understand it's representation in Flash.

Since Flash objects and timelines are hierarchically structured much in the same way as XML is, such a conversion from XML to ActionScript object would seem simple enough as it could be translated fairly directly. However, because of the way XML is defined, there ends up being some complications. Lets take a look back at what the basic XML structure looks like including common node types:

<child attribute="value" attribute2="value2">
Text Node: Child of child.
Text Node 2: Child of second child.
<child attribute="value2" />

What we have are a collection of hierarchically related nodes, some element nodes (some with attributes and some with not) and a couple of text nodes. This adheres to the basic structure and rules of an XML document. The structure is hierarchical with element nodes containing other nodes which they themselves can contain more nodes. The rules to keep in mind here are that elements can share similar names whereas attribute names must be unique.

If we were to take the above and convert it into a similarly structured Flash object, you may get something like the following:

var parent = new Object();
parent.child = new Object();
parent.child.attribute = "value";
parent.child.attribute2 = "value2";
parent.child = new Object();
parent.child.text = "Text Node: Child of child.";
parent.child = new Object();
parent.child.text = "Text Node 2: Child of second child.";
parent.child = new Object();
parent.child.attribute = "value2";

Immediately, you should be able to see at least one apparent problem - the assignment of child. Because XML elements don't need to have unique names, when a new child object is added to the parent object above in Flash, it effectively replaces whatever object was defined there under the same name (the original child).

Also, though far less apparent, is that you have no preservation of order in using object properties to define elements. Given the original XML layout, it's easy to tell which child is first, second, and third - information which could be important to the content (in XML node order is not redundant). With Flash objects, you have no real control of object property order, they exist just as properties. So then, what would facilitate objects in a specific order whose name's don't have to be unique? Hmm... arrays would, right? Keeping each element in an array will allow it not only to have whatever name it wants (it can be stored as a property of an object element in the array - a property under something like "nodeName" perhaps?) but also maintains the order as it is specified within the original XML document. A good array name for holding child nodes of any element may be... "childNodes," don't you think?

What about attributes? Is there anything horribly wrong with them in the Flash object above? Well, for the most part, no. But being assigned directly to an element object could cause confliction with already predefined element values and methods such as those provided by Flash. You shouldn't be restricted from using a certain attribute name just because Flash might use it as an XML property in an XML instance. To keep these separated a bit to avoid such confusion, attribute definitions can be kept in a single object within the element object called... how about "attributes?" The fact that they all need unique names means that they can remain defined under a variable of a similar name instead of needing an array (attribute order is not a factor).

All that remains are text nodes. They seem fine enough. But remember, text nodes are nodes and separate entities of the elements in which they exist. They, like other elements, would be children of their parent element. As such, they too will need to be placed in the childNodes array of the element containing them. Also, in being a node these entities should be created as objects in order to facilitate node properties and methods as Flash may seem fit to provide (as opposed to just being String variables). The actual text can go in a property of that node object called, lets say, oh, I don't know, "nodeValue?"

Wow, things just got a little more complicated. Let's revise the Flash object from above to work with the problems we just solved:

var parent = new Object();
parent.childNodes = new Array();
parent.nodeName = "parent";
parent.childNodes[0] = new Object();
parent.childNodes[0].nodeName = "child";
parent.childNodes[0].attributes = new Object();
parent.childNodes[0].attributes.attribute = "value";
parent.childNodes[0].attributes.attribute2 = "value2";
parent.childNodes[0].childNodes = new Array();
parent.childNodes[0].childNodes[0] = new Object();
parent.childNodes[0].childNodes[0].nodeValue = "Text Node: Child of child.";
parent.childNodes[1] = new Object();
parent.childNodes[1].nodeName = "child";
parent.childNodes[1].attributes = new Object();
parent.childNodes[1].childNodes = new Array();
parent.childNodes[1].childNodes[0] = new Object();
parent.childNodes[1].childNodes[0].nodeValue = "Text Node 2: Child of second child.";
parent.childNodes[2] = new Object();
parent.childNodes[2].nodeName = "child";
parent.childNodes[2].attributes = new Object();
parent.childNodes[2].attributes.attribute = "value2";
parent.childNodes[2].childNodes = new Array();
parent.childNodes[3] = "I'm tired of typing...";

Suddenly that simple XML file isn't looking so simple in its ActionScripted version anymore. And in case you were wondering, the structure above is pretty much exactly how that XML would be laid out in an instance of the XML object in ActionScript. The parent variable here actually represents the first child of an XML instance (the XML instance itself acts like a node containing all XML of that instance within it as a child). Everything else is as it would be within that object. Daunting, isn't it?

Fear not, you're half-way in the know now. We just went through the reasons why this complexity exists which is a large step in helping to understanding it. In summary Flash translates an XML document's structure into an ActionScript object - an XML instance - through the following:

  • The base XML object is an object containing the entire XML hierarchy beneath it (as a child).
  • All children of any given node (including those in the base XML object which is itself a node) are contained within an Array in that object called childNodes.
  • Each Element Node contains a property nodeName (among others) giving its name.
  • Each Text Node node contains a property nodeValue (among others) containing the text.
  • Attributes of an Element Node object are contained with an attributes object in that node object under their respective variable names.


SUPPORTERS:'s fast and reliable hosting provided by Media Temple.