If you are observant, you might have noticed that the latest ECMA Script for XML (aka JavaScript) specification defines, and the latest Rhino release includes, support for literal XML manipulation. If you are inquisitive, you would have discovered that the latest NetKernel release supports E4X on the server-side.
If you haven't seen it, here is a quick overview of E4X.
Anyways, I'm working on a small set of helper functions that, when used, assume your intent is to always manipulate data as XML in the scripts and hides some of the impedance mismatches between the E4X XML object and it's underlying XmlObject.
What's really interesting is that NetKernel shares the underlying model with all called accessors (functions). And if the model needs to be changed (from XmlObject to DOM or SAX, for example) it manages that for you under the hood. So building applications that incorporate XSLT and XQUERY where/when it makes sense, is a snap.
Since JavaScript is interpreted (and "compiled" on the fly), you can easily build up very concise, modular, and layered applications. Concise because of the literal XML support. Modular and layered due to the natural way in which services are composed and aggregated in the NetKernel framework.
So for those of you who like to edit a JSP and hit refresh on the browser to see how the changes took, you can do the same with E4X. But you also gain native manipulation of the XML model (not string concatenation) and 'xunit' tests to verify your service interface.
Leave a comment