Alan Gutierrez

Two weeks back, I began work on an XML template engine. The name came to me shortly after. I’d call it Stencil. I like the name. I’m surprised that it does not already describe a template engine of sorts.

Today, I found another reason to like the name. It is easy to find pictures to accompany posts.

Motivations

When last I approached web applications programming, I was using XSLT and developing an XML pipeline engine called Relay. This engine is still about. I’m a fan of Saxon and XSLT.

XSLT, The T is for Transform

The problem with XSLT is that it is sight too complicated for XML generation. XSLT is a transform language. In order to generate a document from XSLT you need to feed it a bogus document. Then you match the root of the document, but copy none of it. Instead, you write out your new document.

Using this method, dynamic content must be passed in as parameters. A complicated document, with a lot of different dynamic sections, would require a lot of parameters passed to the Template. The invocation of the template looks and feels messy.

Feeding XSLT, With XML Serialization

There are ways to generate a document to get the ball rolling, like using XStream to serialize an object graph, which work rather well. Building map with the objects in them, and then serializing them gave a nice big XML document to roll from.

However, it does not always work, of course. Your object graph has to contain the data. You’ll have a JDBC cursor, for example, that you need to convert into an List, before you can put it in a Map that would also include the user login information.

The output can be very complicated, include a lot of extra data that is undesired, and is not terribly semantic.

There major drawback is that, if all I was doing was laying out a simple signup form, I couldn’t do that layout separately from the development of the form. I needed to start with the object model, serialize it, develop a transform. I’d have to create a pipeline to see what was going on at all.

A lot of complexity for something that once upon a time, was very simple.

JSP, Perpetual Context Switching

JSP hurts my eyes and my brain. I don’t like to see wayward Java injected into that twisty, angle-bracket maze. I don’t like it because it’s not valid XML. I don’t like it because logic has bled into the presentation.

On the client side, I manipulate the DOM with JavaScript, rather than place JavaScript directly in the document. Certainly, in client side JavaScript, there is no concept of a while loop that emits XML. (Okay, there is, but didn’t you get the memo? You’re not supposed to use document.write anymore.)

Two worlds collide.

Display Only XHTML

My ideal template engine would allow me to work on the XHTML separately. Creating the page in XHTML, then adding variable placeholders, and even then, using a utility that would strip the placeholders, view the static XHTML without having to yet implement the object model or controller.

I’d like to get back to the whipitupitude of the HTML and Perl days of yore.

• Stencil Project Page
• Stencil Posts at Blogometer