Was just perusing O'Reilly’s XSLT Cookbook in Books Etc. The guy does some interesting stuff including generating lots of code, e.g. C++ program fragments from UML definitions, diagramming XML with SVG and much more. One thing that caught my eye was using XSLT to populate an HTML form with some data from an XML document.

He had some HTML that didn’t look all that much like:

<form>
    <input type="text" id="city" value=""/>
</form>

The XML would then be something pretty simple. E.g.:

<address>
    <city>London</city>
</address>

The XSLT to combine the two, which I can’t recall exactly right now (it’s in the examples zip file), just copied the template HTML document to the output HTML document, but would apply a template to the element matching input[@id=“city”] which inserts the corresponding data from the XML.

This is slightly more effort in this case than a PHP solution:

<form>
    <input type="text" id="city" value="<?= $city ?>"/>
</form>

However, the advantage is that the input template is kept clean of any syntax other than plain vanilla HTML (or preferably XHTML). This is a tangible advantage. For all the simplicity claimed for server-side languages, particularly JSP custom tags, they are never going to match up to plain old HTML. A distinct bonus is just being able to use whatever editing tool you care for. Although Dreamweaver is very good, relying on it’s abilities to manipulate server-side pages requires that designers understand why they need to use those capabilities and the ramifications of the elements they create. If you can say to someone, “just make me an HTML page with demo data in, set the id’s right”, it’s going to be much more straightforward, especially if the designers belong to another organisation, as is the case in my work sometimes.

This is all very well and dandy for forms, but what about a more general solution? This blog for example uses templates that have conditional and repeating sections as well as access to variables. What would be really nice would be to exploit the fact that CSS layout has lead to careful IDing and classification of many elements in HTML pages. Example:

<div id="blogentry">
    <div class="title">Title</div>
    <div class="date">Posted on <span id="date">date</span></div>
    <div class="content">Content</div>
    </div>
</div>

For the purposes of your designers, you throw them some CSS that styles elements that will be replaced in red or with strikethough or something. Then they can see variables in the document. Then, you’d use XSLT to find the elements they’ve created by ID or class and replace them with the actual blog data, throwing out their demo data, even doing things like applying a template that loops over multiple entries to div[@id=“blogentry”]. As with the original XSLT cookbook example, the only requirement between the designer and the developer is that they agree on which IDs and classes are special. This doesn’t even have to be done ahead of time if it’s a simple project, the designer can just send over the page and the developer can pick out the IDs that the designer has used.