Page 2 of 6
To highlight some of JSP's shortcomings, an MVC litmus test might be useful. Here's the scenario: you'd like to display all the orders a particular customer has made over a certain period of time. This display should have the flexibility of being in an HTML table or in an HTML ordered list. According to strict MVC interpretation, this shouldn't be a difficult task; if presentation is truly independent of data, changing one should have no effect on the other. Unfortunately, in JSP you have two choices, neither of which is attractive. (Take note of where and how the table structure gets filled.)
Vector (or other java.util.List-like object) containing order objects. This Vector is available to the JSP as a JavaBean:<table>
<%
orderVector = customer.getOrders();
for( int i=0; i<orderVector.size(); i++){
Order o = orderVector.elementAt(i);
%>
<tr>
<td><%= o.getDate() %></td>
<td><%= o.getOrderID() %></td>
</tr>
<% } %>
</table>
<javaworld:orderlist/>. After configuring the tag library file and remembering to import the correct tag library at the top of the JSP file, you
can start writing the Java code that looks like the following:...
BodyContent body = this.getBodyContent();
JspWriter writer = body.getEnclosingWriter();
writer.print("<table>");
orderVector = customer.getOrders();
for( int i=0; i<orderVector.size(); i++){
Order o = orderVector.elementAt(i);
writer.print("<tr>");
writer.print("<td>" + o.getDate() + "</td>" );
writer.print("<td>" + o.getOrderID() + "</td>" );
writer.print("</tr>");
}
writer.print("</table>");
...
You can immediately see that neither of these two options is acceptable; each violates the MVC pattern. The first requires
elements of the model in the view. Should the structure of the Order or Customer object change (which is, mind you, part of the model), changes would need to be made to the Java elements present in the
view. That is not good, but it could be worse. In the ideal MVC environment, changes to one element should never affect another.
The second option requires elements of the view in the model. Should you need to change the HTML table (the view) to an unordered list, the custom tag would require modifications. That is even worse than the first option. In addition to violating good MVC practice, the second option forces a recompilation of the code, which implies regression testing, stopping the servers, a new or updated installation, and all the other little evils that ride on the coattails of changing deployed code. There has to be a better way.
In a perfect world, you'd expect your magic bullet to be an open source technology that's compatible with Java but not reliant on it, a strict MVC adherent, and independent of any source file type. Allow me to introduce FreeMarker, an open source project that meets all of the above standards. FreeMarker consists of a class library that provides template processing capabilities and an API that lets you extend or modify FreeMarker's behavior. Like JSP 1.1, FreeMarker's template processing engine replaces tags in the source file with dynamically generated data. Unlike JSP, FreeMarker tags are independent of the source-file format; they can just as easily be placed in an XML file, WML file, HTML file, or plain text file. FreeMarker is actually independent of servlets altogether, making it just as useful on the client as on the server. And unlike the JSP 1.1 XML-configured architecture, FreeMarker provides a lightweight framework that you can easily extend to build a powerful application without relying on runtime-inefficient technologies like Java Reflection to do the legwork. A unique feature of FreeMarker is its support for an embedded template scripting language. As you will see later in the article, this feature helps encapsulate commonly used presentation logic for use across pages.
include expression. It also contains some discussion of custom tags