Clean Templates

Generally, separating logic from the presentation is considered to be a good practice. An obvious way to achieve this is not to put output commands into our code that emit content that does not depend on application logic - let's call this static content.

However, code has to drive the application, so indirection or abstraction is the only way to accomplish this. And that's where template engines come into play. These template engines have to manage the static content that comes from somewhere outside, so called templates. Let's have a look on some examples:

Apache Velocity:

1:  <table>
2:  #foreach( $customer in $customerList )
3:    <tr><td>$foreach.count</td><td>$customer.Name</td></tr>
4:  #end
5:  </table>

Hamlets:

1:  ...
2:  <DIV CLASS="Text">
3:    <REPEAT ID="Comments">
4:      <DIV CLASS="Text">Date: <REPLACE ID="Date">26.9.2007</REPLACE></DIV>
5:      <DIV CLASS="Text"><REPLACE ID="Comment">Hello world!</REPLACE></DIV>
6:      <BR/>
7:    </REPEAT>
8:  </DIV>
9:  ...

But what do we find there? The Velocity example comes with a real loop statement and even Hamlets introduces a block structure <REPEAT/> that implies much more than static content. We might have eliminated static content from our code, OK. But now we have some parts of our code buried in templates stored who knows where?

There are people that claim to not mix presentation and logic because they use a template engine! But as shown by the examples above, using such an engine does not bring clean separation by itself. And now it would be time for some people to emphasize that it is only presentation logic that escaped to the templates. But the holy business logic is still cleanly separated¹. Looking at the velocity example I wonder if it is really not related to the domain model or at least to the business logic if one has a customer list or not. But such fundamental discussions are not my concern here and they were discussed enough elsewhere. Let's consider some other facts:

1. We already use a programming language to build an application.
2. Modern IDEs know a lot about such programming languages and offer much valuable help for working with them.
3. There are many different syntaxes for template languages. They tend not to be so very well supported by IDEs.
4. Integrated support of the application programming language and the template language in an IDE is even less often available.
   Think of debugging and switching between business and presentation logic!

So why do people like to use template engines that come with their own proprietary template language. I can't really explain it but maybe some people like to be able to change part of the logic without involvement of the development team or perhaps the development process: That change is so simple, we don't need to test that.

• A template should be static content with places where some other content can be put.
• The places must be identifiable - most likely by name - so that additional content can be put precisely into the right position. Let's call such a named position anchor.
• It is completely up to the application which uses the template if anything and, just in case, what has to be placed in an anchor.

Following this rules, only the anchor's names connect templates with their application.