The Beauty of REST

Lightweight XML Search Servers, Part 2

Lightweight XML Search Servers

The Social Life of XML

Interactive Microcontent

Note that both of these formats suffer from a syndrome that might be called "div-itis". I've chosen to maintain a browser-friendly XHTML format to ensure that the raw data files are always viewable without special transformation. In fact, that was never completely true: the files contain some fictitious attributes (e.g. 'id' and 'start' in the speakers file) that aren't kosher in HTML, and don't display in the browser.

On balance, I still think it's handy to be able to browse the data file directly. But the techniques I'm exploring in the last column and this one don't require use of XHTML. Indeed, they'll work more easily when element names, rather than attributes, carry the semantics.

It's crucial to be able to visualize data. As browsers are increasingly able to apply CSS stylesheets to arbitrary XML, the XHTML constraint becomes less important. The Microsoft browser has been able to do CSS-based rendering of XML for a long time. Now Mozilla can too. Safari doesn't, yet, but I'll be surprised if it doesn't gain that feature soon. So while I'm sticking with XHTML for now, that may be a transient thing. Of more general interest are the ways in which XPath and XSLT can make XML data (of any flavor) interactive.

An XSLT-driven form generator

Here's a form, driven by both of the data sources, that's used to update information for a session:

Figure 3. The session update form.

The script that builds the form is based on the Zope XSLT wrapper we explored last month. It accepts one argument: the id of a session. That id is used to create a series of form widgets of different types, drawing on different data sources:

Two of these widgets -- sessionTitle and sessionDescription -- are easily made using XPath expressions to pick out the corresponding data from the sessions file, as shown in bold Figure 5. But the rest require more spelunking.

datafile = 'sessions.html'
id = context.REQUEST.form['id']

xsl = '''%s

<xsl:template match="//*[@id='%s']">
<form method="post" action="updateSession">
<div><input type="hidden" name="sessionId" value="{@id}"/></div>
<div>sessionDay: <select name="sessionDay">
%s
</select></div>
<div>sessionTitle: <input size="70" 
      name="sessionTitle" value="{*[@class='sessionTitle']}" /> </div>
<div>sessionTrack: <select name="sessionTrack">
%s
</select></div>
<div>sessionStart: <select name="sessionStart">
%s
</select></div>
<div>sessionEnd: <select name="sessionEnd">
%s
</select></div>
<div>sessionSpeakers: %s </div>
<div>sessionDescription: <textarea rows="10" cols="70" name="sessionDescription">
<xsl:copy-of select="*[@class='sessionDescription']/*" />
</textarea></div>
<div><input value="updateSession" type="submit"/></div>
</form>
</xsl:template>

<xsl:template match="text()" />

</xsl:stylesheet>'''

xsl = xsl % (context.xsltPreamble(), id,
             context.makeList('sessionDays', "@day"),
             context.makeList('sessionTracks', "*[@class='sessionTrack']"),
             context.timesAsSelectWidget ( context.sessionsAsDict()[id]['start'] ),
             context.timesAsSelectWidget ( context.sessionsAsDict()[id]['end'] ), 
             context.speakersAsSelectWidget(id),
             )

result = context.xslt(xsl, datafile)

result = context.adjustSelectWidget ( result )

Because this is a Zope application, the SELECT widgets for sessionDay and sessionTrack can use lists of values stored as ZODB properties. That means an authorized administrator -- a non-programmer, presumably -- can edit the lists using Zope's through-the-web management interface.