Ted Patrick > { Events & Community } > Adobe Systems

The XML Object is a collection of objects and properties structured to conform with the Document Object Model. The key is that it is a hierarchy of objects containing internal references.\0

I often structure objects/classes in this manner as they provide a simple way to nest objects in objects. The problem is managing the nested objects in a relative manner. By default Objects do not understand the hierarchy they are contained within from an internally perspective. Take this object for example:

//Florida feeding hierarchy
alligator = {dog:{ cat{ mouse:{ cheese:{} } } }

The cheese object has no idea that it is within the mouse, same with mouse, cat, and the dog in the alligator. This hierarchy is fundamentally location independent as _parent, ../ references do not exist.

Worse still if I come along and make a direct reference to cheese:
myCheese = alligator.dog.cat.mouse.cheese

I have no idea that myCheese is within mouse or in a hierarchy at all.

Worse still is that if I am the cheese object, I cannot know the names of my references (with the exception of reference counting). Cheese doesn't know it is cheese and neither does mouse, cat, dog or alligator. It is sort of like inner amnesia, Who am I?

Not that I am complaining about how this works, objects should be clueless internally. This is a very good thing but it can cause problems if you do not understand how it works. Objects are reference based in the player, eliminate all references and your object is swept up by the garbage collector.

The XML Object provides inner references to eliminate these problems. My hierarchy would look like so if it were an XML Object:

alligator = new XML('<dog><cat><mouse><cheese/></mouse></cat></dog>')

The inner hierarchy is composed of individual XMLNode objects mapped into a hierarchy by references. You can then externally or internally walk this hierarchy in a structured way once the XML has been parsed into its object representation.

So how do we fix our hierarchy to be self referencing? Easy lets add some properties.

Child Objects are easy as you can simply reference them by name. Walking down the hierarchy is easy but walking up the hierarchy is typically the problem. There are 2 properties you need to provide:

_parent = A reference to the container object
_name = A property string of the instance name of the object you are within.

Both of these should seem familiar as it fits into the MovieClip hierarchy pattern. I use these names so that objects and MovieClips subtly become in sync during development. It is a bit confusing as first, but it elevates many of the problems in self-referencing objects. The fact that we must treat these two dataTypes unequally is a major problem in the player. (Rant, Rant!)

One issue here is that N references can point to an Object but you should only want the hierarchy walked up in one direction. If there were 2 references to an Object, from within the object how would you know which way to go, confusing. Or how would you know there was a reference at all? The Player knows, but as of yet we cannot know programatically (Hint, Hint, Nudge, Nudge!).

alligator = {_name:'alligator'}
alligator.dog = {_parent:alligator,_name:'dog'}
alligator.dog.cat = {_parent:alligator.dog,_name:'cat' }
alligator.dog.cat.mouse = {_parent:alligator.dog.cat , _name:'mouse ' }
alligator.dog.cat.mouse.cheese = {_parent:alligator.dog.cat.mouse , _name:'cheese' }

The tree ends up looking like a link list except cast into an object hierarchy. For example assume I am scoped within cheese all of these tests are now true:

this._name == 'cheese'
this._parent._name == 'mouse'
this._parent._parent._name == 'cat'
this._parent._parent._parent._name == 'dog'
this._parent._parent._parent._parent._name == 'alligator'

Ideally this hierarchy would be created via a class so that the properties _name and _parent would be added without getting procedural. Mouse might have a method eat(target) allowing it to consume the cheese object and configure the references correctly. Also when you destroy the objects, you should delete the inner references so the object will be garbage collected, inner references will keep an object in memory. It also might be nice if Macromedia would shine some light on this subject for all of us.(Hint, Hint!)

Cheers,

ted ;)