As I mentioned before, I eschewed using a large web framework solution and instead wrote simple servlets that used a small template engine. I thought I would describe some of my feelings on template engines in general and Freemarker in specific.

Let’s go back in time, shall we? You remember the good ol’ days after the Java servlet specification came out… we all thought that while CGI may be bad and clunky, the servlet spec did a pretty good job— except for the missing pieces.

At first we were looking for the following two features:

1. User authentication
2. Templating

Sure, the servlet spec gave us limited session management (even though we were really wanting control flow but actually authenticating the user without resorting to the ugly basic web authentication, required something more.

The JSP spec tried to address the templating issue, but at first just made things worse. Let’s hang on to this templating concept for a bit— and by templating, I am referring to a solution that did not require spitting out HTML from inside your application… yeah, that holy grail often called MVC.

A slew of “web frameworks” suddenly appeared to address these and other perceived limitations with servlet/JSP programming. Struts is probably the current pop star, but there are many options. Once upon a time, I wrote my own since at the time, all the other options were in their infancy.

Almost without exception, each of these frameworks that felt the need to have a template engine, also decided to invent a new language to be embedded in those HTML-oriented templates. It didn’t start that way, they didn’t mean to, but they had to…

It all began with something along the lines of “Let’s just scan the template and substitute every occurrence of $blah with the value of blah.” Sounds noble, eh? (Keep in mind that while the syntax may vary between each framework, the concepts are pretty much the same).

At first, the simple variable substitution was fine, but what about displaying a variable number of rows from a database query? “Well, we’ll add a blurb for doing loops, but we aren’t going to make this a programming language!”

What about optionally displaying a section based on the value of some variable? “Well, alright, we’ll add an if…then construct, but no more… Hey, if we can do a test for existence, we might as well do full conditional expressions!” Pretty soon, a complicated, but not-complete language was invented to be used in the template. And the world becomes a mess.

To add insult to injury, you often can’t get just the template engine without getting it far uglier sisters, as most “web frameworks” consists of a complete solution for implementing the “controller” and “model” in the MVC pattern.

FreeMarker

I was first exposed to Freemarker last year, and at first I thought it was a wonderful idea. I liked its small size and single-jar mentality. I liked the concept of generating all values to be plugged into the template before hand and even liked the syntax… but then the problems started to occur.

At first it was just annoyances… I would have a tag, ${address} that may or may not exist. If it didn’t exist, instead of no displaying the value, it threw an exception. I then had to litter my templates with ${address?if_exists} … not very pretty, but understandable.

Another issue is their rendering concept. Each value passed needed to be wrapped in a special object, and if they didn’t have an equivalent object wrapper, it threw an exception. I spent a lot of time developing JDBC components that would wrap the resulting data sets into standard Java types (granted, these are useful components).

But my biggest issue is the fact that Freemarker (along with just about any other template engine) attempts to be a language… but does a poor job of it… and programming web pages (and debugging them) is not a good idea.

StringTemplate

I recently ran into this article by Terence Parr and thought I had been saved. He echos my frustration of herding cats (programmers and graphics designers). For while I can insist on the tool they use, I can’t always check with how they use that tool.

Terence Parr came up with a very simple template engine called StringTemplate, and while at first looks a little strange, it ends up working pretty well.

My only gripe with it is the fact that it only deals with the following objects:

• Simple scalars (by calling the object’s toString() method)
• Arrays (for dealing with lists of data)
• Read-only JavaBeans (where $bean.data$ results in a call to data.getData() method)

What I would like to see is support for the collections in java.util like Map and List as I really don’t like the unnecessary work involved in creating data structures when there are already nifty-swell, already-debugged, solutions available to every Java application.