Today, our web-applications based on java are clunky and harder to maintain.
I`ll walk you through – what it is like to develop a web application using a couple of popular tools that are available today. I will try to give a nice first person account of what it is like to use these technologies on a daily basis.
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.
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: look at Velocity with examples.
In this blog, 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.
Comparison Veloctiy vs. JSP:
1. The biggest advantage of Velocity over JSP is that the code is more organized and not clunky – no scriptlets are required. In JSP, one needs to embed “code” within
<% %> tags and for Velocity, tags are not required.
Unlike JSP, Velocity Template Language (VTL) can be used 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.
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.
2. 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.
3. 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.
Advantages of Velocity -There’s Much More than that:
The mentione three points are the major ones to take decision to make a choice between Velocity and JSP. 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.
Velocity, most popular for code generation, is the only framework to give such a level of flexibility. Most of the real-world code generators, both commercial and open source releases, use templates and template engines. The Velocity generator takes an XML representation of classes and data members and generates the Java code to define them. The generation process is driven by a template that encapsulates the syntax of the target programming language. It’s beautiful.
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.
My impression has been that Velocity is very popular in code generation and “open source-ish” 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, I see better prospects for Velocity.