Introduction to XML in Flash
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
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:
- Text Node: Child of child.
- Text Node 2: Child of second child.
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
Node: Child of child.";
Node 2: Child of second child.";
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
Node: Child of child.";
Node 2: Child of second child.";
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
- 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