For editing XML, I wanted to have some sort of template system, where XML markup could be abstracted into a simpler system for reusability and flexibility. I didn’t know of any standardized template system like that, so I wrote one.

Designing the mental model proved relatively easy: XBL’s anonymous content design was inspirational with its <xbl:children/> element. I also needed a repetition model, though, so I came up with a repeat element as well (very different from Web Forms 2’s repeat element). I also wanted to separate the UI from the actual output of the templates. Finally, I wanted to provide, in the design, at least, placeholders for custom XML and JavaScript to override what the template normally does.

Making all that work took a lot longer. So long, in fact, that I created an “experimental” section of Verbosio’s CVS repository to work on it in a minimal-code environment, long enough to get the basics working.

I finished the functionality parts of the XBL bindings two days ago. Then, because I knew no one but me would know how the thing worked, I spent several hours documenting it.

Verbosio’s markup language specification, version 0.1.0.

For those of you with XULRunner trunk, and a desire to see some of it in action, read the full article link for details on testing it.

Next on Verbosio’s agenda: creating the XUL wizard for creating markup templates from already-existing XML markup. If you want to edit XUL, XHTML, etc., and you’ve got samples on hand, this tool would guide you through creating templates you and everyone else could use. Good stuff cooking.

Instructions for executing the test code

Execute the following:

# password is guest
cvs -d :pserver:guest@mozdev.org:/cvs login
cvs -d :pserver:guest@mozdev.org:/cvs co verbosio
path/to/xulrunner verbosio/experimental/templates/application.ini

Hopefully you’ll have a debug build, so you can see dump() output

. The large text box on top is where you would enter source code to run against the template. Samples of markup for the templates can be found in a comment at the end of verbosio/experimental/templates/chrome/content/editorTest/elementTemplate.xul .

The first row of radio buttons lets you determine what the test application does. “Walk sample only” means to use the test application’s tree walker (not the native Gecko TreeWalker, as I’ll explain in a moment) to walk the nodes of the XML fragment you pasted into the source box.

The “Walk template only” radio button means it will walk its own internal template (which you select in the second row), just as it would for the “Walk sample only” selection. You can use this radio button, no matter what you’ve put into the source box.

“Walk with sample” means to walk both the template’s markup and your XML fragment’s markup simultaneously, in parallel. (This is why I couldn’t use the native tree walker – it walks one tree at a time, and I felt it would be just more efficient to write my own walker.) The idea is to see if the template matches your fragment, much like a regular expression would match a string.

“Import node” is the magical one. It takes the XML fragment you’ve given it and attempts to import it into the template, using the special XBL bindings to do the needed work.

The second row of radio buttons lets you select templates. The “Ordinary markup” selection chooses a rather unimaginative MathML template. The “<markup:children/&gt” selection goes for a template using <svg:g/> and any number of child elements. The “<markup:repeat/>” selection uses a more complex template for a XUL radio group and any number of XUL radio buttons.

I haven’t yet tested combinations of <markup:repeat/> and <markup:children/>, like you might find in a XHTML table (tables with repeating rows, rows with repeating cells, cells with arbitrary content). So it’s not fully validated yet. That would be a real litmus test for the template markup language, and I’ll look into it a little later.