Why would I use a templating engine? jsp include and jstl vs tiles, freemarker, velocity, sitemesh

Question

I'm about to choose to way to organize my view (with spring-mvc, but that shouldn't matter much)

There are 6 options as far as I see (though they are not mutually exclusive):

• Tiles
• Sitemesh
• Freemarker
• Velocity
• <jsp:include>
• <%@ include file="..">

Tiles and Sitemesh can be grouped; so can Freemarker and Velocity. Which one within each group to use is not a matter of this discussion, there are enough questions and discussions about it.

This is an interesting read, but can't quite convince me to use tiles.

My question is - what do these frameworks give that can't be properly done with <@ include file=".."> and JSTL. Main points (some taken from the article):

1. Including parts of pages, like header and footer - there isn't a difference between:

   <%@ include file="header.jsp" %>
   

   and

   <tiles:insert page="header.jsp" />
   

2. Defining parameters in the header - like title, meta tags, etc. This is very important, especially from SEO point of view. With the templating options you can simply define a placeholder which each page should define. But so you can in jsp with JSTL, using <c:set> (in the including page) and <c:out> (in the included page)

3. Layout reorganization - if you want to move the breadcrumb above the menu, or the login box above another side-panel. If page inclusions (with jsp) is not well organized, you might need to change every single page in such cases. But if your layout is not overly complex, and you put the common things in header/footer, there is nothing to worry about.

4. Coupling between the common components and the specific content - I don't find an issue with this. If you want to reuse some fragment, move it to a page that doesn't include any header/footer, and include it wherever needed.

5. Efficiency - <%@ include file="file.jsp" %> is more efficient than anything else, because it is compiled once. All other options are parsed/executed many times.

6. Complexity - all non-jsp solutions require additional xml files, additional includes, pre-processor configurations, etc. This is both a learning curve and introducing more potential points of failure. Also, it makes support and changing more tedious - you have to check a number of files/configurations in order to understand what's happening.

7. Placeholders - do velocity/freemarker give anything more than JSTL? In JSTL you put placeholder, and use the model (placed in request or session scope, by controllers) to fill these placeholders.

So, convince me that I should use any of the above frameworks instead of/in addition to plain JSP.

Solution 1

A few arguments for Velocity (I haven't used Freemarker):

• Potential to re-use templates outside of a web context, such as in sending emails
• Velocity's template language syntax is far simpler than JSP EL or tag libraries
• Strict separation of view logic from any other sort of logic - no possible option to drop down to using scriptlet tags and doing nasty things in your templates.

Placeholders - do velocity/freemaker give anything more than JSTL? In JSTL you put placeholder, and use the model (placed in request or session scope, by controllers) to fill these placeholders.

Yes, references are really the core of VTL:

<b>Hello $username!</b>

or

#if($listFromModel.size() > 1)
    You have many entries!
#end

Efficiency - <%@ include file="file.jsp" %> is more efficient than anything else, because it is compiled once. All other options are parsed/executed many times.

Not so sure I agree with or understand this point. Velocity has an option to cache templates, meaning the abstract syntax tree they are parsed into will be cached rather than read from disk each time. Either way (and I don't have solid numbers for this), Velocity has always just felt fast for me.

Layout reorganization - if you want to move the breadcrumb above the menu, or the login box above another side-panel. If page inclusions (with jsp) is not well organized, you might need to change every single page in such cases. But if your layout is not overly complex, and you put the common things in header/footer, there is nothing to worry about.

The difference is, with a JSP approach, wouldn't you be re-organzing this layout in every JSP file that uses the same header/footer? Tiles and SiteMesh allow you to specify a base layout page (JSP, Velocity template, etc - both are JSP frameworks at their heart) where you can specify whatever you want and then just delegate to a "content" fragment/template for the main content. This means there would be just one file to move the header in.

Solution 2

The choice between jsp:include and Tiles/Sitemesh/etc is the choice between simplicity and power that developers face all the time. Sure, if you only have a few files or don't expect your layout to change very often, then just use jstl and jsp:include.

But applications have a way of growing incrementally, and it can be hard to justify the "stop new development and retrofit tiles (or some other solution) so we can fix future problems more easily", which is required if you don't use a complex solution in at the start.

If your sure your application will always remain simple, or you can set some benchmark of application complexity after which you will integrate one of the more complex solutions, then I'd recommend not using tiles/etc. Otherwise, use it from the get-go.

Solution 3

I'm not going to convince you to use other technologies. For all I know everyone should just stick to JSP if it works for them.

I work mainly with Spring MVC and I find JSP 2+ in combination with SiteMesh the perfect match.

SiteMesh 2/3

Provide decorators to be applied to the views mostly like inheritance works in other templating engines. Such feature is unthinkable to work without nowadays.

JSP 2+

People claiming that JSP will make it hard to avoid Java code in templates is bogus. You just shouldn't do it and with this version it's unnecessary to do so. Version 2 supports calling methods using EL which is a big advantage compared to previous versions.

With JSTL tags your code will still look like HTML so it's less awkward. Spring packs a lot of support for JSP through taglibs which is very powerful.

The taglibs are also easy to extend so customizing your own environment is a breeze.

Solution 4

One of the best arguments for facelets (not in your list, but I'll just mention it) opposed to using JSP is that the compilation is integrated with the interpreter instead of being delegated to the JSP compiler. This means that one of the most annoying things I had with JSF 1.1 - having to change the id-attribute on a surrounding JSF-tag when saving a change in order for the runtime engine to discover the change - went away, giving the save-in-editor, reload-in-browser cycle back, along with much better error messages.

Solution 5

A good view technology eliminates most and most anoying if/switch/conditional statements, simple include does not. Using a 'complex' view technology results in a 'simple' application.

View more solutions

Comments

[Bozho]

Yes, for JSF facelets is the solution just because of the tight integration with the interpreter. But here this is not the case :)

[matbrgz]

I just mentioned it in case any of these had the same feature - that would be a decisive feature to me.

[Bozho]

the velocity examples you give can be easily done with JSTL. with the efficiency point I mean that the jsps are compiled to servlets, and nothing gets parsed. But caching templates is also a good solution, yes. as for the reorganization - no, I usually form includes in a way I only have to modify the includes, not the "includers". Perhaps in more complicated cases this is not possible.

[user2012801]

Besides reusing templates out of web context, Velocity lets you easily grab rendered web page before it is displayed to the client. It is useful when you want to make your site to be generated as HTML files. With JSP - no easy solution. This was the primary reason why we switched to Velocity from JSP. About speed - I did some benchmarking and Velocity was rendering pages exactly 2 times faster than JSP. So speed is not an issue. Now after spending with Velocity few years I will never go back to JSP again. It is so much simpler, lighter and cleaner.

[matt b]

@serg555 do you have those benchmarks posted anywhere? I'd love to see more data about this. I'd be interested to see how you performed the benchmark too. I think this would be good info for others pondering the same "Velocity vs JSP vs other engines" question.

[user2012801]

I don't have the results posted. Just I converted several pages from our site and measured rendering time before and after. Nothing too scientific :)

[Bozho]

@serg555 what was the platform/servlet container/version of jsp ?

[user2012801]

@Bozho: winxp/tomcat 5.5/jsp 2.0. It was about 3 years ago, maybe somethign has changed in JSP world since then.

[Magnus]

I see no benefit to SiteMesh. Jsp tags offer the same decorating functionality as SiteMesh but with greater flexibility, less brittle setup, and I'd speculate greater efficiency too since no post-process parsing is involved.