JSP or Velocity: It is your decision!
- 0 Comments
The purpose of this blog is to check out what it is like to develop a web application using a couple of popular tools that are available today. In order to get this way, some points of using these technologies will be shown. This will give a nice first person account of what it is like to use these technologies on a daily basis.
The intended audience are the people who are working on web tier and want to weigh the possible options, which are available in market and have strong user’s view. This write up is mainly differentiating and weighing two technologies, which have strong perspective in current market scenario that is JSP Vs Velocity.
I have been working on Velocity for the last 18 months and I got chance to work on one of our ecommerce projects based on spring framework. Luckily, I got my next project on same technology and got opportunity to enrich my understanding with this powerful template language.
Introduction to Velocity:
Let me define Velocity to those who are not aware of this. Velocity is an open source and a Java-based template engine, which designed to give Web designers an easy way to present dynamic information to users of a Web site or application. It can be useful in any Java application areas that require data formatting and presentation.
To get more detailed information with some basics and samples please try the following link: Start with Velocity with examples.
What to be compared?
I have a handful experience on JSP. But, to be clear that we are not really trying to compare the feature set of each of these technologies as they both can get the job done and also not focusing that Velocity outperforms the JSP. Instead, we are trying to compare what it is like to do the job with each of the tools as per my understanding.
Evaluate your decision:
The biggest advantage of Velocity over JSP is that no scriptlets are required. In JSP, one needs to embed “code” within <% %> tags and for Velocity, tags really not require. You can simply use the Velocity Template Language (VTL) directly in any portion of the template. The benefit (and loss) of the embedded code is that the JSP code within a page will not show up when the file is simply loaded into the browser. On the other hand, like in debugging, there might be a case where one may desire it to show up.
A good developer knows that embedding HTML code within Java code is a not good design decision because it makes it more difficult to modify the look and feel of an application on later point of time. It also ruins the concept of MVC separation where the View (ie: HTML) display of the page is separated from the Model and Controller. Let us more clearly with an example:
JSP:
<html>
<head><title>Hello</title></head>
<body>
<h1>
<% if (request.getParameter(”name”) == null) %>
Hello EBW !
<% else %>
Hello, <% request.getParameter(”name”); %>
</h1>
</body>
</html>
Velocity:
<html>
<head><title>Hello</title></head>
<body>
<h1>
#if ($request.getParameter(”name”) == null)
Hello EBW !
#else
Hello, $request.getParameter(”name”)
#end
</h1>
</body>
</html>
The outcome is that, however, you still need to embed the necessary <% %> tags everywhere. More the typing == ,more the chances for mistakes! There is also a bit of a disconnect as to when the “;” needs to be added and when it does not. With Velocity, the rule is that you place a # before a directive and a $ before a member in the Context. The advantage is that it is easier to debug problems because all of the logic in template remains visible which are missing in JSP.
The second major vantage of Velocity over JSP is no servlet container required in order to check results. JSP flaunt an advantage that it takes an existing .jsp page and compiles that into a Servlet for speed and efficiency reasons. The point being that this whole process of edit->transform->compile->load->run is really unnecessary and in particular, a bad design. On the other hand, Velocity will simply load templates, parse them a single time and then store an Abstract Syntax Tree (AST) representation of the template in memory which can then be re-used over and over again. The process is simply edit->parse->run. The benefit is that working with Velocity templates ends up being much faster and it also removes the requirement of having a javac compiler and temporary scratch directory hanging around. In Velocity, when the template changes, the existing cached template is simply replaced with a freshly parsed version. The other important thing is that the actual template data can be stored anywhere, including a database or remote URI. By using configurable template loaders, it is possible to create template loaders that can do anything that you want.
The third point is dealing with effective error handling. It should be analyzed that while working with JSP, How many different types of errors can we get? For example, because the JSP Servlet is auto generated from a .jsp text file and then compiled with a compiler, what happens when there is a generation/parsing error or a compile error? The unnecessary complexity of JSP actually increases the number of ways to get errors!
The ugliest aspect of all of this is the fact the errors are reported via two different mechanisms. The parser can throw its own set of errors and the javac compiler can throw a whole different set of errors and as a result of the layers of generation, errors from the compiler generally do not make any sense whatsoever. For a example, a developer missed “;”after any line. Do you think that a non-java or new to java could have figured out the error quickly and easily? Compound that with the fact that if the error had been on a less deterministic part of the file, it is now much harder to find the source of the error because there is a level of abstraction from the original .jsp file and because there is an intermediate java file that gets generated.
Here, Velocity avoids these problems because there is no intermediate step and no layers of abstraction.
<%@ page errorPage=”/error.jsp” %>
JSP allows you to display an error page that is used if a Throwable exception is thrown during the processing of a page. This is also against the MVC model. In case to throw an exception somewhere in a JSP page, you need to first embed it within a statement. Velocity overcomes all these problems because it does not allow the author to place any Java code within a template. Only, Template Language (VTL) and method calls are allowed in the template.
Other Important aspects:
Above-mentioned three points are the major to take decision to make choice between these two technologies. Apart from them, there are some important aspects, which can also help you in your decision.
Velocity is easy to use and to integrate into any Servlet application. One of the profound features of Velocity is the clear separation Java code from the web pages, making the web site more maintainable over the long run and providing a viable alternative to JSP or PHP.
On the server side, you can use Velocity to process templates and generate dynamic content (HTML, XML, and so on). This is very similar in purpose to JSP technology. However, the JSP model provides unhindered access to the underlying Servlet API and Java programming language. In fact, to avoid access to these native features, you will have to exercise great discipline in coding (using only EL, tag libraries, and the like). Essentially, this is a wide-open access model.
Contrast this with Velocity. Being a completely self-contained template engine and script interpreter, Velocity has a completely closed model. Access to anything specific to the system and/or the Java programming language must be explicitly enabled. By default, there is no access within a Velocity template to any facet of the Java programming language. This closed model allows Velocity to provide a decoupled templating presentation layer, cleanly separated from any application business logic or data management code.
At last, I would like to add that Velocity is a nice product because of its features of simple and concentrates on a single aspect of your web architecture it can be easily integrated into almost any web development project.
Conclusion:
It is not to force anyone to believe that the Velocity is the “Right Way”, but instead to let people see the differences between the two approaches and allow one to develop their own opinions about the tools that are in use today.
My impression has been that Velocity is very popular in code generation and “open sourceish” applications, but rarely used in big “corporate” applications. So, as we are moving to SME’s, like a new path to IT development with the new option.