So you have this great community-based website. People are making profiles, uploading images and videos, voting on who's got the hottest dress and 'snagging' each other's cakes. What you need now is an interactive map that not only shows you where all of the parties are and how many people are going to be there, but also links you to the host's profile page so you can check out the car daddy is getting them for their birthday. OMG, you need XML!

Okay, so no one is likely to be squealing over the code behind the party map that Killswitch recently built for one of our entertainment clients—this kind of dynamic user data-driven application isn't even all that new. But I have to admit that I got a little excited over this and other similar projects that we've been doing at Killswitch thanks to the combination of ActionScript 3 and Ruby on Rails and how they handle XML.

These projects usually follow the pattern of users upload some sort of content (party info, images etc. ), data about that stuff gets stored in a database (city, name, longitude, latitude, file paths), then it's packaged up as XML and passed on to the flash movie (map) where that information is dressed up in its party outfit.

The benefit of using Rails on the back end is that it makes accessing the database and generating xml an easy, elegant and painless process. It can be as simple as adding one line of code:

render :xml => @parties.to_xml

Which parties this refers to is of course determined by the find conditions you set when the @parties object is created. If more control is needed—maybe there are fields in the database we don't want to make public or there is some sort of reformatting we want to impose on the data—we can render a template instead. This is done similarly to an html template.

ActionScript 3 is beneficial for the same reason that working with XML in Rails is convenient. It is nearly automatic. In previous versions of ActionScript if I wanted to get the name of the second guest attending a party as represented by this excerpt of XML:

<party>
  <host>Seth</host>
  <location>Chicago</location>
  <guests>
    <guest>Jasper Johns</guest>
    <guest>Julie Mehretu</guest>
    <guest>Robet Rauschenberg</guest>
  </guests>
  <time>9pm sharp</time>
</party>

I would have to write something like this:

//assuming the xml is loaded into partyXML
var second_guests = partyXML.firstChild.childNodes[2].childNodes[1].firstChild;

This is not exactly very legible and becomes less so as we go deeper down the xml tree. What's worse is what happens when someone decides to change the structure of the tree. If time were listed before guests, we'd be looking for a list of names somewhere inside "9pm" and that wouldn't be conducive to anything good. The assignment to second_guest would have to be rewritten.

One alternative would be to write a function that parses the xml and formats it into an object that can be easily referenced later, but I'd rather spend my time animating something. After all, that is what flash is good for. This is where ActionScript 3 wins some praise. These days all it takes to find the second guest coming to my party is:

var second_guest = partyXML.guests.children()[1]
// returns "Julie Meretu"

Finding the time would be:

var start_time = partyXML.time
// returns "9pm sharp"

It is intuitive, legible and clean. I don't need to know the order in which things are listed in the xml. I only need to know how they are nested and what the tag names are. Not only does this save the headaches of maintaining cryptic code when the xml structure is changed, but it also saves a lot of time—time better spent on perfecting shape tweens or tricking out the user interface.

So there it is, your dynamic XML birthday cake fresh from the Rails bakery, ornately decorated with a layer of Flash-icing. Everybody nosh.