On templating, and a shameless plug of Moulder

Moulder is a server-side templating system. It uses jQuery’s approach, i.e. select and transform, and works only on XML-like data. I’ve written it two times over: One time in Java and another in Scala. Both versions are available as Open source software on GitHub and released under the MIT License.

1. What is templating

Templating is generally used in (but not limited to) web applications to generate dynamic web pages. Every time you perform a search on Google or open your Facebook page, templating was used behind the scene to generate these pages.

Templating is a technique used to generate content that starts from a pre-made and static template. This template is then transformed using some specified rules and steps to generate the desired result.

There are many different ways to do templating, and the wealth of templating libraries that can be found is a proof to that, but I sort of categorize them in two categories: embedded and separate.

2. Templating rules embedded in the template text

In this type of templating libraries, the templating rules are embedded in the template file and are expressed in a specific language.
JSP, Freemarker, Velocity, Facelets, and many others fall in this category.

In the case of JSP, the templating rules are written in Java and are wrapped in a special tag (<%). The following snippet shows an example of JSP:

<ul>
  <% for(int i=0;i<10;i++) { %>
	<li><%= "item n°"+i %></li>
  <% } %></ul>

Other libraries may and do introduce their own templating language like for Velocity (from Velocity’s User guide):

<table>
#foreach( $mud in $mudsOnSpecial )
   #if ( $customer.hasPurchased($mud) )
      <tr>
        <td>
          $flogger.getPromo( $mud )
        </td>
      </tr>
   #end
#end
</table>

Freemarker (from its developer guide):

<ul>
<#list animals as being>
	<li>${being.name} for ${being.price} Euros
  <#if user == "Big Joe">
     (except for you)
<!--#list--> <#-- WRONG! The "if" has to be closed first. -->
<!--#if--></li>
</ul>

2.1. Advantages

Embedding the templating rules in the template file offers higher readability, as the rule sits right next to the code it operates on.

Also, this kind of templating can handle any kind of template format (html, css, js, etc.).

2.2. Drawbacks

Having the rules in the same file as the template means that at leat two different languages are used in that file: one for the original template, and another for the rules. This makes it harder to use regular editors and still enjoy auto-completion, syntax highlighting, etc.

JSP like templating libraries use Java to write the templating rules. While this gives us a powerful language to express all kinds of templating rules, it makes it possible to embed any kind of code in the template file, even business logic or database code. This, and I hope we do agree on it, is a bad practice.
This is mitigated by some templating libraries, like Velocity and Freemarker, where only a reduced set of instructions can be expressed by the templating rules language. But, these specific languages are far less powerful than Java and usually don’t have Java-like editing experience (syntactic coloring, auto-completion, type safety, etc.)

But in my humble opinion, the main drawback is that designers and developers will have a hard time working on the same file, especially the designers who don’t necessarily understand the templating rules language, and can easily break the whole thing when trying to modify the file.
Also, when provided with a new version of the template text (say, a new version of the HTML from the designers), it’ll be hard to incorporate the modifications into the original template with all the template rules scattered inside it.

I’ll also link to this post: Why this fuss about scriptlets and taglibs ? that talks more about JSP-like tempalting solutions drawbacks.

3. Templating rules and template text living in separate files

The templating rules and the template live in separate files.
XSLT and Wicket are some templating libraries that fall in this category.

Here’s a sample of what XSLT looks like (from the w3c schools tutorial):

<table border="1">
    <tr bgcolor="#9acd32">
      <th>Title</th>
      <th>Artist</th>
    </tr>
    <xsl:for-each select="catalog/cd">
    <tr>
      <td><xsl:value-of select="title"/></td>
      <td><xsl:value-of select="artist"/></td>
    </tr>
    </xsl:for-each>
  </table>

And here’s how Wicket’s templating capabilities look like:
The java part (templating rules):

ListView list = new ListView("list", listModel) {
	@Override
	protected void populateItem(final ListItem item) {
		item.add(new Label("text", item.getModelObject()));
	}
};
add(list);

And the html part (the template data):

<ul>
	<li>text to be replaced</li>
</ul>

3.1. Advantages

The template text and the templating rules live in separate files. These files can each be edited in its specific editor, so no custom editors that support both languages are needed.
Also, designers and developers will be able to work on their respective files without risking to step on each other’s toes.
Finally, integrating new versions of the template text can be as easy as copying and pasting the new version in its corresponding file. Such modifications can still break the templating process, but at least you’ll be spared the pain of finding out what changed in the new version and updating the combined template text/templating rules file accordingly.

3.2. Drawbacks

Having the template text and templating rules in separate files make harder to see how they interact.
Also, such a kind of templating requires the templating rules mechanism to have a specific knowledge about the format of the template text (XSLT works only for XML files), and so they usually are limited to a single format.

4. Moulder

Moulder is a templating library where the template text and templating rules live in separate files. It can only handle XML like formats (including HTML). The templating rules are expressed in Java or Scala. It mimics jQuery in that the templating rules are composed of a selector and a list of operations to perform on the elements matching the selector.

4.1. Selectors

The selectors are Strings containing jQuery-like (or CSS) selectors. Most of the selectors listed here should work in Moulder.

4.2. Operations

Moulder contains a couple of operations, such as setting an element’s text, manipulating attributes, appending/prepending content, repeating, hiding, replacing, etc.

4.3. Moulder in 5 minutes, or an example shamelessly stolen from Moulder’s readme file

Given this markup (kept very simple on purpose) :

<h1>text to be replaced</h1>

And these templating rules, in Scala:

[...].register("h1",
           repeat("Summer" :: "Autumn" :: "Winter" :: "Spring" :: Nil))
           :: attr("class", Values("even" :: "odd" :: Nil).cycle)
           :: text(eData())
           :: append(h(tr(eData[String](), (c:String)=>"<p>"+ c +"</p>")))
           :: Nil)

Or in Java:

[...].register("h1", 
        repeat(Arrays.asList("Spring", "Summer", "Autumn", "Winter")),
        attr("class", new Values<String>("even", "odd").cycle()),
        text(new ElementDataValue<String>()),
        append(new ValueTransformer<String, String>(new ElementDataValue<String>()) {
                protected String trandform(String s) {
                        return "<p>" + s + "</p>";
                }
        }));

The following is produced:

<h1 class="even">Spring<h1/>
<p>Spring</p>
<h1 class="odd">Summer</h1>
<p>Summer</p>
<h1 class="even">Autumn</h1>
<p>Autumn</p>
<h1 class="odd">Winter</h1>
<p>Winter</p>

Or in plain english:

• For each item in the list of seasons, repeat the h1 element
• For each generated h1 element, set its class to even or odd
• Also set it’s text content to the corresponding season
• And finally, append a paragraph after it with the season name as its content

This was a quick showing-off of Moulder. A detailed explanation should follow in another blog post. In the mean time, you can get moulder from Github (The Java version and The Scala version) and build it using maven. You are also encouraged to signal bugs or ask for new features using Github issues system, and of course to fork it !