if you are currently looking for alternatives to jsp and youre tired of reinventing the wheel each time, then this article can provide you with the solutions you need to build your web applications. well explore what its like to develop a web application using a couple of popular tools that are available today - and ill use examples to show what its like to use these technologies on a daily basis.
ill start by comparing usage of velocity and jsp. in both cases, we have a framework of reusable code that makes life easier for building web applications by providing the "model" and "controller" portions of the mvc paradigm (turbine and struts). there is also a template language that provides the "view" portion (jsp and velocity).
first lets start with some easy examples. well show more complicated examples later in the article.
we will not compare the feature set of each of these technologies as they both can get the job done. instead well compare what its like to do the job with each of the tools.
in the first example, we show two different approaches to doing the same thing using jsp and velocity (see figures 1 and 2). listing 1 is an example of printing out a parameter with jsp, and listing 2 with velocity. (the listings for this article can be found on the jdj web site, www.javadevelopersjournal.com.)
the primary difference between the two is the way output is performed. with jsp you need to embed "code" within<% %> tags; you dont with velocity. simply use the velocity template language (vtl) directly in any portion of the template.
the benefit (and detriment) of the embedded code is that the jsp code within a page wont show up when the file is simply loaded into the browser. however, there might be times when you want it to show up (for example, in debugging).
another issue with jsp is that even the most basic examples start to blow the whole mvc paradigm right out of the water. the reason is that embedding html within java code is a bad design decision; it makes it more difficult to modify the look and feel of an application at a later date. it also destroys the concept of mvc separation in which the view (html) display of the page is separated from the model and controller. for example, if just the word "hello" had to be in bold, we would need to embed<b> </b> tags into the out.println() statement.
of course, people in the know would recommend that we write jsp as in listing 3, or with struts as in listing 4. figure 3 shows the new jsp when the code in listing 3 is loaded directly into the browser.
the point is, to make jsp "pure", you need to jump through hoops. figure 3 looks similar to figure 2, however, you still need to embed the necessary <% %> tags everywhere. more typing - more chances for mistakes! theres also a bit of a disconnect as to when the ";" needs to be added and when it doesnt. with velocity, the rule is that you place a # before a directive and a $ before a member in the context.
as you can see from the example image, theres now a bit more information in the displayed page, except its also missing all the logic that was used to build the page. if you view the equivalent velocity template directly in the browser without it being rendered first, all the logic in the template remains visible. the advantage is that its easier to debug problems.
jsp touts as an advantage that it takes an existing .jsp page and compiles it into a servlet for speed and efficiency reasons. this means that it first parses the .jsp page into a java file, then uses javac or your favorite java compiler (e.g., jikes) to compile that servlet into a .class file, which is then loaded by the servlet engine.
the point is that using jsp is now a multistep process. the authors of jsp have done a good job of hiding this process behind the scenes in such a way that you dont even notice it. you simply edit the .jsp page in their favorite editor and then use their browser to call the pa... 下一页