Choosing the right template engine

Question

Hi there,

since today - I always used simple JSP Tags and JSTL which works but now I'm looking for a little bit more features and maybe more usability.

With googling I've found Freemaker, Velocity and Tiles which seem to be very famous. Does someone of you has some further experiences with some of these and can give me a short brief about it.

Or are there other frameworks which are worth to look into?

Answer 1

• Velocity is the old man of java template engines, and it shows it. The design is a bit crusty (lots of static methods), and it's a bit limited and not very extensible. It works perfectly well, though, and integrates well with Spring MVC.
• Freemarker started where Velocity left off. It's got a lot more functionality, it's very extensible, it integrates very nicely with Spring MVC. On the downside, I find the template expression language to be highly peculiar.
• Tiles I have no experience with, although any association with Struts makes me suspicious.

When it comes to view rendering, I still use JSP and JSTL. For all their flaws, they still give the best range of options, in my opinion.

When it comes to rendering dynamic textual documents outside the scope of the web layer (e.g. SMS or email templates), Freemarker wins hands down, for me.

Answer 2

In my opinion, with templating engines, less is more. That is, you want fewer features, not more, to promote re-usability of the templates.

One templating engine that provides only the functionality that a templating engine strictly needs, and no more is StringTemplate. It's not something I've personally used in a production system, but am planning to the next opportunity I get.

If you're interested in learning more on the subject/philosophy, please read Enforcing Strict Model-View Separation in Templating Engines by the creator of StringTemplate.

If you read only one section in that paper, read chapter 7, which includes the following rules I try to enforce (even when using something like JSP, that's arguably "too powerful" an engine):

1. the view cannot modify the model either by directly altering model data objects or by invoking methods on the model that cause side-effects. That is, a template can access data from the model and invoke methods, but such references must be side-effect free. This rule arises partially because data references must be order-insensitive. See Section 7.1.
2. the view cannot perform computations upon dependent data values because the computations may change in the future and they should be neatly encapsulated in the model in any case. For example, the view cannot compute book sale prices as “$price*.90”. To be independent of the model, the view cannot make assumptions about the meaning of data.
3. the view cannot compare dependent data values, but can test the properties of data such as presence/absence or length of a multi-valued data value. Tests like $bloodPressure<120 must be moved to the model as doctors like to keep reduc- ing the max systolic pressure on us. Expressions in the view must be replaced with a test for presence of a value simulat- ing a boolean such as $bloodPressureOk!=null Template output can be conditional on model data and com- putations, the conditional just has to be computed in the model. Even simple tests that make negative values red should be computed in the model; the right level of abstraction is usu- ally something higher level such as “department x is losing money.”
4. the view cannot make data type assumptions. Some type assumptions are obvious when the view assumes a data value is a date, for example, but more subtle type assumptions ap- pear: If a template assumes $userID is an integer, the pro- grammer cannot change this value to be a non-numeric in the model without breaking the template. This rule forbids array indexing such as colorCode[$topic] and $name[$ID] The view further cannot call methods with arguments be- cause (statically or dynamically) there is an assumed argu- ment type, unless one could guarantee the model method merely treated them as objects. Besides graphics designers are not programmers; expecting them to invoke methods and know what to pass is unrealistic.
5. data from the model must not contain display or layout information. The model cannot pass any display informa- tion to the view disguised as data values. This includes not passing the name of a template to apply to other data values.

Answer 3

I have worked with both Velocity and Freemarker along with Spring MVC. Although Velocity is really light-weight and easy-to-use, it is somehow limited. I prefer Freemarker for web page rendering because of large existing macro libraries and JSP inclusion support.

I also recommend SiteMesh for web page decoration to avoid a template file mixing content with decoration.

So, if you do not need the fantasy of AJAX pages, the result is: Freemarker+SiteMesh+Spring MVC. But if you are wondering whether to use AJAX or not, I recommend you to take a look at GWT showcase.

Answer 4

If you like the Scala programming language you might like Scalate as it allows you to use powerful Scala expressions instead of the limited JSP/JSF/JSTL EL expression language - while being completely statically typed so that templates are checked at edit/compile time for errors.

The Scaml templates in Scalate let you write really DRY templates which are particularly good for XML/HTML (Rails fans tend to love Haml and Scaml is the Scala port of Haml) - though if you're used to JSP you'd probably be better off starting with Ssp templates in Scalate which are JSP-like.