Alan Gutierrez

Read up on Cross Site Scripting and be careful of it as you develop applications that allow users to inject markup into the data they enter.

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

At the outset, Strata was developed for use with in memory and file backed implementations of tiers.

When in memory, branches and the objects can be stored in arrays. The default implementation uses ArrayList classes to store objects.

When file backed, their are two types of objects that can be stored, variable length objects and fixed length objects. Objects can be stored within the tiers or by reference.

When file backed, tiers are softly or weakly referenced, so that they can be collected. Thus, they can act as caches of the objects they reference.

Storing by refernece means storing an address. Whether or not the object is stored in the tier, or by reference outside the tier, the object needs to be in memory for comparisons, for traversal at both the leaf and the inner tier.

By reference storage can keep the object within the in memory tier, or it can perform a look up of the referenced object. The object is an simple object, like a string, it might be easier to keep it in the memory tier, as part of an address, object pair. If it is a complicated object, it can load the object through a caching mechanism.

These were once the objectives for Strata, reflecting an early understanding of the project. I’m about to rewrite them, so I thought I’d put them somewhere, besides the wiki history.

Thus, the short-term objectives for Strata are as follows.

• Leaf nodes only to store references to file positions, not store the data itself.
• Branches also store only references to file positions, and hold a list of objects read from those file positions to use as keys.
• Thread-safe.
• File backed, paged.
• Supports efficent insertion and deletion, while maintaining the balance of the B-Tree.
• Equality comparison query.
• Compares byte buffer ranges, not objects.

Crazy thoughts included storing partial in the inner tiers on pages, but this presents a strange case where a partial key might not fit on a page, if the length of a key is unbounded.

What changed? For the first two points, only the way I’d state them. Since it’s now a given, I don’t know if I’d state them. There are also a few more devils in those two details, only the fields of interest may be cached for example.

“Equality comparison query”, meant that the only operator supported is the equality operator, which is also given, but that’s all you need to implement between, less than, greater than, etc. Probably could not see that then.

“Compares byte buffer ranges, not objects”, the meaning of this has escaped my memory.

The crazy thoughts are reflections on how to store the objects referenced by the B+Tree. There was a time when I thought that the objects might be stored in the pages of the tree.