Yet more E4X irritations
I'm finding E4X to be one of those weird technologies that is alternately utterly wonderful and incredibly irritating. The ability to treat XML data as any other JavaScript data structure allows very fast app development and messing around, but every so often I find myself amazed at how awful the syntax is.
Today's irritation is about E4X attributes.
// a perfectly normal E4X object.
var myXML = <xml foo="bar">content</xml>;
// the attribute with value 'bar'
var myAttribute = myXML.@foo;
Easy. I love this stuff. Unfortunately, Zimki, my company's product, uses uneval to store complex objects, and the myAttribute variable there would count. uneval won't produce JSON but it does produce a string that, when run through eval, will probably produce the original data structure, and we store that string in a database to store object.
Not so for E4X nodes. Playing in the SpiderMonkey JS console,
js> uneval( myXML );
<xml foo="bar">content</xml>
js> uneval( myAttribute );
bar
The first one is fine. That string will eval nicely back to the original E4X object. But the 'bar' there isn't valid JavaScript - eval won't restore the original object. In fact, had the original XML been something like:
<xml foo="delete_all_zimki_data()">bar</xml>
and we'd tried to use eval/uneval to store this XML, we'd have executed the attribute as JavaScript. Ick.
Unusually, Rhino handles this much better (normally I find Rhino lags in features..):
js> uneval( myAttribute );
<>bar</>
Not really an attribute node any more, but at least it's valid JavaScript and won't destroy my server.
I don't even have a good solution for this. Right now I'm fudging E4X nodes in the storage engine, but I really feel that attribute nodes should uneval to something a little more sensible. Perhaps I'll be able to produce a patch to SpiderMonkey, if I have time..