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:

  <% 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):

#foreach( $mud in $mudsOnSpecial )
   #if ( $customer.hasPurchased($mud) )
          $flogger.getPromo( $mud )

Freemarker (from its developer guide):

<#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. -->

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">
    <xsl:for-each select="catalog/cd">
      <td><xsl:value-of select="title"/></td>
      <td><xsl:value-of select="artist"/></td>

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

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

And the html part (the template data):

	<li>text to be replaced</li>

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:

           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:

        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/>
<h1 class="odd">Summer</h1>
<h1 class="even">Autumn</h1>
<h1 class="odd">Winter</h1>

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 !

5 Responses to On templating, and a shameless plug of Moulder

  1. Khaled says:

    I am wondering how does it compare to http://mustache.github.com ?

    • jawher says:

      Mustache falls in the embedded category, whereas Moulder is in the separate category.
      Other than that, Mustache is a very elegant templating system, and I’m even toying with the idea of implementing it 🙂

  2. joseph says:

    * Templating rules embedded in the template text

    There is a technical boundary between the template file and the rest of the application’s code. I know of no tools handling both sides at the same time. As such, when refactoring on one side, the other isn’t tackled. As the templating most likely can only be done at runtime, and may be even tricky to get at (display of the broken code could be conditional), the mismatch can be hard to find and fix.
    => extra drawback

    As for readability, heavy scripted templates can easily be hard to read imho (and between html, css, javascript and scriptlets, it can be hard for the editor to properly display the whole). Finally, lot of templates engines (lift/JSF for example) also introduces extra notions which makes the html behind even harder to get or see.

    * Templating rules and template text living in separate files

    Although XSLT is a valid example, I think it’s kind of a poor one, because XSLT introduces another “boundary” between application code and rendering of some of its content. In fact, I’ve often seen XSLT templates to be “no go area” in projects: once done none is willing to touch them again… To avoid as well IMHO

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

    the template file example is a bit confusing:


    => don’t you need properly formed xml ? Like having as well the ?

    Would have been nice as well to the Java version of it. Having read but not used scala yet, the scala example is a bit hard to read.

    BTW, what about making a (x)html tag descriptor library ? It would minimise the use of “h1” and similar, and maybe even allow better reuse/type safety:
    H1 title = new H1();

    […].register(title […])

    => has to be cleared out a bit more for sure, yet I hope I’ve presented enough of the principle 😉

    However, the concept is intriguing: one could think of creating template file with no application related “code” or “identifier”. On the other hand, I wonder how you plan to tackle subset of an html page and composition of these subset templates => maybe there’ll be more h1 that I thought…

    A final question: which use case for this library? Does it play in any way with wicket?



    • jawher says:

      Thanks Joseph for your thoughtful and constructive comment !

      extra drawback

      Indeed !
      But, the same also applies for the templating engines of the embedded kind. With Wicket for example, there is the what-so-called component/html hierarchy hell. Moulder isn’t immune to this either, as a template can be broken by something as simple as renaming a class in the html/css side.

      To be honest, I LOATHE XSLT and everything it stands for. I would rather be skinned alive by a pointless knife and left to die very slowly than to voluntarily use XSLT 😀

      It’s just that I couldn’t find that many templating engines in the separate category.

      the template file example is a bit confusing:

      The “[..]” is the exact textual content of the h1 element and is not a contraction for other elements.

      Stuff like <?xm l, even in the code tag drives WordPress nuts. So does the html tag.

      But I admit that […] is a bit confusing. I’ll change to something less confusing.

      Would have been nice as well to the Java version of it. Having read but not used scala yet, the scala example is a bit hard to read.

      I understand. I’m going to add the Java version.

      BTW, what about making a (x)html tag descriptor library

      I already had this in my “areas where Moulder could be improved” list. Funny thing that you came up with it though 😛
      I was also thinking about maybe including HTML builder capabilities to Moulder, but more on that in coming posts.

      On the other hand, I wonder how you plan to tackle subset of an html page and composition of these subset templates => maybe there’ll be more h1 that I thought…

      Yep, Moulder handles this with the SubMoulder concept. Again, I hope I’ll get to explain things more in details in the coming installments.

      A final question: which use case for this library?

      Well for templating in general, or more precisely, to generate XML like documents, especially HTML documents in web applications.

      Does it play in any way with wicket?

      I’m afraid not. Moulder’s philosophy is too different from Wicket’s.

      Moulder is more adapted to other frameworks like Spring MVC, Play!, etc. I hope I can find the time (and will) to write down bridges to use Moulder in these frameworks.

  3. agentgt says:

    Over the years I have grown to hate templating languages. Moulder looks similar to my library JATL http://code.google.com/p/jatl/

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: