The Problems
with JSP (JavaServer Pages)
Page II
Enter
Template Engines
But
why suffer the complexity of JSP just to do templating? Might it
not be better to use a dedicated template engine? By using a template
engine intended for this exact use instead of the general-purpose
JSP, the underlying design can be cleaner, the syntax clearer, the
error messages more meaningful, and the tool more customizable.
Several companies have built such engines, the most popular probably
being WebMacro (http://webmacro.org, from Semiotek)
whose engine is free.
Using a dedicated template
engine instead of JSP offers several technical advantages that developers
should be aware of:
Problem
#1: Java Code Too Tempting
JSP makes it tempting to
put Java code in the Web page, even though that's considered bad design.
Just as Java improves on C++ by removing the ability to use global
variables and multiple inheritance, so do template engines improve on JSP
by removing the ability to put raw code in the page. Template engines
enforce good design.
Problem
#2: Java Code Required
Doing mundane things in JSP
can actually demand putting Java code in the page. For example, assume the
page needs to determine the context root of the current Web application to
create a link to the Web app home page:
In
JSP this is best done using Java code:
<ahref="<%=request.getContextPath()
%>/index.html">Home page</a>
You
can try to avoid Java code using the
<jsp:getProperty> tag but that leaves you with the
following hard-to-read string:
<a href="<jsp:getProperty
name="request"
property="contextPath"/>/index.html">HomePage</a>
Using a template engine there's no Java code and no ugly syntax.
Here's the same command written in WebMacro:
<a href="$Request.ContextPath;/index.html">Home
page</a>
In WebMacro, ContextPath
is seen as a property of the $Request variable, accessed using a
Perl-like syntax. Other template engines use other syntax
styles.
As
another example where JSP requires Java code in the page, assume
an advanced "view" needs to set a cookie to record the user's default
color scheme. a task that presumably should be done by
the view and not the servlet controller. In JSP it requires Java
code:
<% Cookie c =
new Cookie ("colorscheme", "blue");
response.addCookie;%>
In
WebMacro there's no Java code:
#set
$Cookie.colorscheme = "blue"
As
a last example, assume it's time to retrieve the color scheme cookie.
For the benefit of JSP, we can presume also there's a utility class
available to help since doing this raw with getCookies()
is ridiculously difficult. In JSP:
<%
String colorscheme = ServletUtils.getCookie (request, "colorscheme");%>
In WebMacro there's no need for a utility class and it's always:
$Cookie.colorscheme.Value
For graphics artists
writing JSP pages, which syntax would be simpler to
learn?
JSP 1.1 introduced custom
tags (allowing arbitrary HTML-like tags to appear in JSP pages executing
Java code on the back end) which may help with tasks like this, assuming
there becomes a widely known, fully featured, freely available,
standardized tag library. So far that has yet to occur.
Problem
#3:Simple
Tasks are Hard
Doing even a simple task
such as header and footer includes is overly difficult with JSP. Assume
there's a "header" template and a "footer" template to be included on all
pages, and each template includes in its content the current page
title.
In
JSP the best way to do this is as follows:
<%
String title = "The Page Title"; %>
<%@ include file="/header.jsp" %>
Your content here
<%@ include file="/footer.jsp" %>
Page creators must not forget the semicolon in the first line and
must make sure to declare title as a Java String. Plus, the /header.jsp
and /footer.jsp must be made publicly accessible
somewhere under the document root even though they aren't full pages
themselves.
In
WebMacro including headers and footers is done easily:
#set
$title = "The Page Title"
#parse "header.wm"
Your content here
#parse "footer.wm"
There are no semicolons or
String types for designers to remember, and the .wm files are found in a
customizable search path, not under the document root.