XLEFF - an XML Layout Engine For Flash

The current implementation of XLEFF includes a class that you can reuse conveniently and independently in your own projects: the XModel class.

The purpose of the XModel class is to convert XML data into an ActionScript object whose properties are named after the elements and attributes in the XML data.

ActionScript already comes with a built-in class, called XML, which allows you to load XML data into a Flash movie. The XModel class improves upon the built-in functionality by:

• Reducing the amount of code required to access the XML data.
• Making your application-specific code much more readable and, therefore, much easier to extend and maintain.

From XML to ActionScript

XML is widely adopted because capable of capturing information in a format that can be easily shared among different platforms and technologies.

Such potential is exposed in the following XML snippet describing an object that you can recognize without further ado:

<car manufacturer="Ferrari" model="F430">

<engine>4.3 L V8</engine>

<dimensions length="4.512" width="1.923" height="1.214" />

<seats>2</seats>

</car>

It is easy to realize that the previous XML snippet describes a Ferrari car even without any knowledge about XML!

Moreover, XML facilitates grabbing further details about the car such as the model or the engine but, unfortunately, such readability is lost once that the data is parsed into ActionScript by utilizing the built-in XML class.

Comparing the XModel class with the built-in XML class

Every ActionScript developer who utilized the XML class knows how awkward it is to access XML data by using it.

The structure of the ActionScript object created by the XML class after parsing some XML data is rich of properties that tell you nothing about the XML element they are associated with. Most of those properties are anonymous (childNodes?) and some of them (attributes?) are frequently redundant.

The XModel class tackles this by generating an ActionScript object whose properties are named after the XML elements and their attributes.

The next few examples will show you the convenience of using the XModel class by comparison with the typical use of the XML class.

Accessing the data stored in an XML attribute

The task of the first comparison is to access the value of the manufacturer attribute and display it in the Output window by using a common trace statement.

If successful, both examples will show the "Ferrari" value in the Output window.

Accessing the manufacturer attribute by using the XML class, requires coding something like:

trace(xmlObj.childNodes[0].attributes.manufacturer);

Accessing the same data utilizing the object generated by the XModel class requires a much shorter and more readable statement:

trace(car.manufacturer);

The differences in readability between the two options are evident:

• The XModel class does not group the XML attributes of an XML element into an attributes object, making them directly accessible as properties of the object associated with the XML element.
• The XML class creates structures that are anonymous (childNodes, firstChild, etc.), while the XModel class creates objects that are named after their associated XML elements as will be further emphasized in the next case.

Accessing the data stored in a text XML element

In this second example I want to access the text value stored in the XML element called seats and show it in the Output window.

The XML class forces me to write code that is even more awkward than in the previous case:

trace(xmlObj.firstChild.childNodes[2].childNodes[0].nodeValue);

On the contrary, the XModel class offers once again the chance to achieve the same result with a much shorter and more readable statement:

trace(car.seats[0].text);

The next section provides a complete example to show you how to use the XModel class so that you can make your own experiments.

Using the XModel class

The use of the XModel class follows the same event-driven approach that is broadly used in Flash applications:

• Create a listener object and register it so that it listens to a specific event (onModelledObject) triggered by an XModel instance.
• Implement an onModelledObject event handler as a method of the listener object.
• Load an XML file using an XModel instance.
• Access the XML data in the ActionScript object generated by the XModel class for your own purposes.

The following script applies all of the previous steps, loading an example.xml file that contains the XML snippet showed earlier in this article.

import org.XLEFF.XModel;

var listener = new Object();

listener.onModelledObject = function(eventObject:Object):Void {

    var car:Object = eventObject.modelledObject;

    trace(car.manufacturer);

    trace(car.seats[0].text);

}

var xModel:XModel = new XModel();

xModel.addEventListener("onModelledObject", listener);

xModel.load("example.xml");

Discussing how to handle events is beyond the scope of this article. There are numerous sources explaining that, including my recent book (Mastering the Flash Component Architecture).

If you are already familiar with the event drive approach, all you need to know to start playing with the XModel class is that:

• XModel supports a load method similar to the one implemented by the XML class.
• Once that it has converted the XML data into an ActionScript object, XModel triggers an onModelledObject event.
• The ActionScript object created by the XModel class is returned as a property named modelledObject of the event object.

You can download the source code of the examples in this article at the bottom of this page to start experimenting with the XModel class and make your comparative tests with the built-in XML class.

This article source code