XML MATTERS #b1: MochiKit Lift up your DOM manipulation of XML David Mertz, Ph.D. Dialectician, Gnosis Software, Inc. August 2006 MochiKit is a useful and high-level library for Javascript, that helps with both Ajax tasks as such (as much as such are well defined), and anything else you might want to do with Javascript. MochiKit takes its main inspiration from Python, and from the many conveniences the Python standard library offers; but on the side it also smooths over the inconsistencies among browser versions. MochiKit.DOM is a particularly handy component that lets you work with DOM objects in much friendlier ways than "raw" Javascript provides. A lot of MochiKit.DOM is customized for XHTML work, which possibly makes its use of XHTML wrapped "micro-formats" (previously discussed by Dethe) particularly convenient when combining MochiKit and Ajax. INTRODUCTION ------------------------------------------------------------------------ In the next couple articles, I will look into some themes my recent guest columnist, Dethe Elza, has addressed in his several installments of this column. He has presented a number of interesting ideas surrounding AJAX, microformats, and Atom that I think bear further exploration. As a first step, this installment will look at a wonderful ECMAScript library that Dethe touched on briefly in his "picoformats" article: Bob Ippolito's [MochiKit]. MochiKit contains a number of nice enhancements to basic Javascript ("ECMAscript", technically) capabilities, mostly inspired by a combination of Ippolito's fondness for functional programming, and his love of Python's rich standard library and flexible constructs. In many ways, [MochiKit] lets you program in Javascript while pretending you are using the (to many developers) friendlier Python language. Why XML? As readers of this column will well know, the "X" in "AJAX" is there largely because ECMAscript, as implemented in web browser, more-or-less supports the W3C DOM specification (depending on your precise browser version, the "less" may dominate the "more"). Which is just a fancy way of saying that your Javascript code automatically has a parser for XML and (X)HTML documents, along with a collection of API calls to traverse, search, and modify those documents as abstract structures. It seems like a natural fit; except for the awkward fact that the DOM is a remarkably awkward API. While there might be an argument for using the formality of the W3C DOM for a strongly and statically typed, highly structured, and carefully encapsulated, language like Java--what we scripting programmers call a "bondage-and-discipline language"--there seems little motivation for it in a comparatively "agile" language like ECMAScript. A reader might be inclined to wonder why she should bother with the XML part at all, even given what [MochiKit.DOM] makes easier. After all, JSON is essentially just a native Javascript data structures (that by happy coincidence is simultaneously valid Python), which is lighter still. Nonetheless, XML retains some advantages. On one hand, in presentation contexts, XML is well able to be styled directly with CSS2. You can, of course, -transform- JSON into a stylable DOM object, but that essentially just means moving back to XML or (X)HTML. On the other hand, a lot more tools outside the ECMAScript interpreter itself are happy to talk XML than know how to talk JSON. Data may arrive from--or be delivered back to--servers that use XML to define structured data. In some cases, this XML may follow well-known and well-defined schemas, including ones that conform to published standards. If some other system in the overall communication flow wants to communicate using SVG, or OpenDocument, or TEI, or some ebXML standard, there are probably good reasons not to insert JSON as an extra layer in that mix. Simple Magic Fortunately, [MochiKit.DOM] builds on what W3C DOM is intended to do--provide an API for abstract document structures--while making the easy things easy, and the hard things still a lot less hard than they are in W3C DOM. The real magic in [MochiKit.DOM] is its willingness to flexibly coerce various types of objects into the right types during method calls, including doing so recursively. [MochiKit] assumes that if there is one obvious -right thing- to do, there is no need to make a programmer jump through hoops in casting types or calling methods to extract or mutate out the thing we need. Moreover, [MochiKit]'s FP-inspired partial application lets a programmer (and a program) be lazy just when it is most convenient to be so. WHAT'S THE BIG DEAL ABOUT HTML? ------------------------------------------------------------------------ Obviously "web pages" are usually written in (X)HTML, or often in something resembling HTML while not actually quite -being- HTML. I confess that "quirks mode" of browsers do pretty remarkable jobs. But with wide implementation of CSS in modern browsers, -any- XML document with suitable styling works equally well, and can, in fact, let you use the specific tags of interest to the semantics of your document. Nowadays, it is largely possible to think of (X)HTML as just that XML schema that comes with a default CSS stylesheet. The parity of generalized XML with (X)HTML is nice for AJAX contexts. Most of the examples that come with MochiKit wind up parsing XML or JSON into HTML tags; but a more conceptually "pure" style of sticking with XML is largely possible. For a few example, I will use the same '' XML format that MochiKit uses for its "ajax_tables" example, but put it to slightly different use. First let us try to style the table suitably. A simple CSS stylesheet might look like: #------------------------- table.css ----------------------------# datatable { display: table; width: 99%; border: solid 1px; margin-left: auto; margin-right: auto } columns { display: table-header-group; background-color: lightblue; } column { display: table-cell; font-weight: bold; border-right: solid 1px; } rows { display: table-row-group } row { display: table-row } cell { display: table-cell; border-right: solid 1px; } You can pretty well infer the structure of a styled XML document from this CSS, but let us go ahead and look at one of the data files we use: #------------------------ table1.xml ----------------------------# First_name Last_name Domain_name Dethe Elza livingcode.org Bob Ippolito bob.pythonmac.org Not much too it, and you can perfectly well publish this static document. Readers of it can see something like: {Screenshot of Firefox displaying 'table1.xml': http://gnosis.cx/publish/programming/table1-xml.png} MANIPULATING THE XML ------------------------------------------------------------------------ Of course, just displaying styled XML does not need AJAX, and does not need MochiKit. So let us work up to some code that -does something- with the XML. For a start, let us wrap up our XML goodness with some old-fashioned HTML page. Sure, we could use the magic 'xml:link' attribute to adding XLINK capabilities; but let us keep it simple for now: #-------------- table project index.html home -------------------# DOM made simple

[Show current XML] [Show text of table]
[Load table1.xml] [Load table2.xml] [Add row of data]