JSP and Tag Libraries for Web Development

PotPieMan writes "I recently finished reading JSP and Tag Libraries for Web Development, a book for JSP developers wanting to improve their skillset. Read on for my review." It's not a new book, but still relevant. JSP and Tag Libraries for Web Development author Wellington L.S. da Silva pages 420, including appendices publisher New Riders rating 6 reviewer PotPieMan ISBN 0735710953 summary A guide to designing and implementing JSP applications, with a focus on tag libraries.

The Scoop Web developers and designers have long wrestled with strategies for combining their efforts. Web developers don't mind looking at code but dislike dealing with the look of a page, while Web designers are the opposite. Dynamic Web page technologies, such as Microsoft's ASP, Perl's many template systems and Web frameworks (Text::Template, HTML::Template, HTML::Mason, CGI::Application, etc.), and PHP, were designed to give both developers and designers a chance to do their work without stepping on each other's toes.

Sun's answer was to release the Servlet API and later extend that to make JavaServer Pages. Initially, there was no clear role separation for servlets and JSPs, since a servlet could generate and display HTML just as easily as a JSP could perform business logic. The Model 2 architecture, based on Smalltalk's Model-View-Controller (MVC) design pattern, showed that servlets and JSPs complemented each other. Tag libraries extended the functionality of JSPs in a way that made it easier for developers and designers to collaborate.

JSP and Tag Libraries for Web Development is mostly targeted at Web developers who want advice on designing JSP applications and incorporating tag libraries. The book covers custom tag libraries, the Jakarta Struts framework, and various commercial and noncommercial tag libraries, such as Jakarta Taglibs.

What's to Like? The author starts with an introduction to servlets and JSPs, including a decent explanation of MVC. If you are comfortable with servlets and JSPs, this discussion is really more of a review than anything else.

The next two chapters introduce tag libraries and the author's example application (a simple article and author tracking system). The author illustrates the lifecycle of a tag, which helps if you haven't really used or written custom tags before. Da Silva also gives a very detailed discussion of tag library descriptors (TLDs). Some details might have been better left as an appendix, but it is nice to see such a comprehensive explanation of what you can put in a TLD.

Da Silva then spends about 100 pages on writing simple tags, iteration tags, body tags, and making all of these types of tags cooperate. The discussion is again very detailed, but seems unfocused in many parts. Very little of the code in these chapters ties in with his example application.

Next, the author spends three chapters on the Jakarta Struts framework. He explains how Struts naturally fits into the MVC design pattern and gives various examples of how to structure your Struts application. He also includes an entire chapter on finishing his example application, going over Struts ActionForms, Struts Actions (including a method to prevent double submission that I had not seen before), and Struts' method of internationalization on JSPs.

Finally, the author runs through the Jakarta Taglibs project and some commercial tag libraries. Brief examples are provided, but this chapter really needed more attention than da Silva gave it.

What's to Consider Overall, JSP and Tag Libraries for Web Development feels unfocused. The author's central points are explained well in many places, but lost in many others. With some reorganization, I think the book could make a much stronger case for appropriate uses of tag libraries, both application-specific and general (e.g. Struts and Taglibs).

Sections where general tag libraries are discussed read very much like the documentation available on project Web sites, such as the struts-html tag library documentation. These really should have been left as an appendix, with better explanations and usage examples provided in their place.

I was also very disappointed in the author's use of Struts Action classes. He combined various actions (add, edit, delete, etc.) to perform on a specific object and tested for a URL parameter to decide what to do. In my opinion, each action should be encapsulated in one Action class (AddObjectAction, EditObjectAction, and DeleteObjectAction). The author's design leads to URL hackery which Struts tries to avoid.

Recently, Struts released a stable version of the 1.1 series, which this book does not cover (it was published in early 2002). Readers should be familiar with the Struts documentation for this release before picking up this book.

The book's Web site is under construction, and I've been able to find little information on the publisher's site.

The Summary A okay book with room for improvement. While the author shows his technical knowledge, the book loses its direction in places. Most developers can probably get by with the documentation available on the Web. Table of Contents

1. Understanding the Tag Library Extension API
2. 1. Introduction to Servlets and JavaServer Pages
   2. Introduction to Tag Libraries
   3. Writing Custom Tags
   4. Cooperating Tags and Validation
   5. Design Considerations
3. The Struts Framework
4. 1. The Jakarta Struts Project
   2. Struts Tag Libraries
   3. Anatomy of a Struts Application
5. The Jakarta Taglibs and Other Resources
   1. The Jakarta Taglibs Project
   2. Commercial Tag Libraries
   3. Other Resources
6. Appendices
7. 1. Tomcat
   2. Allaire JRun
   3. Orion
   4. MySQL
   5. Mapping Servlet-JSP Objects
   6. The Apache Software License, Version 1.1

You can purchase the JSP and Tag Libraries for Web Development from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

What about Cocoon?

[ThatDamnMurphyGuy]

Not to mention AxKit in those lists of templating systems?

Other JSP books

[grennis]

A great list of other introductory JSP books can be found here...

Web

[Slack0ff]

You said that most of this is avaiable on web. Would there be any real reason to buy this book then? Does it offer anything special or unique? I might have missed where you said this in your review. If i did. Sorry.

Re:Web

[PotPieMan]

I was referring primarily to the documentation available on the Struts site. Their user guide and taglib documentation is generally very good.

Re:Web

[gfxguy]

Any compendium of information has inherent value over the labor (time) it would take to do it yourself. Wether or not it's worth it depends on how much you need the information and how much money you think it's worth to not have to find it all by yourself.

Re:Web

[redJag]

This doesn't necessarily apply to this book, but in general it is nice to have a hard copy. I like it because it has an index (although this can be done on the web, it often isn't), it doesn't take up screen real-estate / you don't have to click back to your tutorial and then back to your code, and it looks good on the book shelf :P

check what's there.

[Anonymous Coward]

if it doesn't include JSTL and JSF technologies.

DON'T BUY IT!

This book looks seriously out of date.

Servlets vs. JSP for HTML output

[easter1916]

Initially, there was no clear role separation for servlets and JSPs, since a servlet could generate and display HTML just as easily as a JSP could perform business logic.

This isn't true. You can output HTML from a Servlet, that much is sure, but it is much smarter (and less work) to use a JSP instead. Think of all those out.println("") statements if you were to use Servlets... ugly!

Re:Servlets vs. JSP for HTML output

[BigGerman]

believe it or not, in the env I am in right now people were using JSPs but _still_ use out.println() inside Java scriptlets!
The whole "view in MVC" discussion is way above the level of average developer.

Re:Servlets vs. JSP for HTML output

[jester]

actually there is little or no difference. It is not 'smarter' to use JSP, just personal preference. Think of it like this ... JSP is basically HTML with Java embedded, whereas servlet is Java with HTML embedded. What do you prefer to edit is a suitable question.

As for the 'println' point with servlets, you can wrap all those calls up into java objects. So for example if you want a HTML table, you could wrap it up in a Table object, and add rows, columns using Java, and then have a method on the table class that is toHTML(). You could even add a method toXML() etc etc. Look at the WebUtils library if you want one example that does this.

One possible benefit of JSP is allowing you to have a web-designer write the pages. The only thing here is that they need to be familiar with some JSP to plug in the use of beans and get methods to populate the values in pages. A lot of projects embed *a lot* of java in pages and this removes this possible advantage.

There are many arguments I've heard from people about JSP being better etc, but it really comes down to what you and your company/project team are comfortable with.

Re:Servlets vs. JSP for HTML output

[MillionthMonkey]

Oy- is that what you think the good thing about JSP is? Getting rid of out.printlns?

Frankly I'd rather work with a servlet that has out.printlns. At least you can figure out a way to abstract them away with some sort of template mechanism. I work with a large servlet based application and I never even see the out.printlns. In fact, I rarely even see the servlet. All the page layout stuff is contained in special files that are edited by design people. We have a special syntax that the servlet parses and replaces with chunks of calculated data. (And that's all the servlet should do. Unless it's a really trivial application, you should immediately abstract all your hard work away from that level- a servlet or JSP should not be among the files you're editing on a daily basis as a developer. Its job should be simple- to handle the interaction with the web server, and that's it.)

You could do that with a JSP and the JSP bean syntax, I guess, but it seems nobody does. JSP makes it too easy for people to write things that are basically servlets with the out.printlns stripped and surrounded with %> and <% punctuation. There's code all over the place doing loops, SELECTs, try/catch/finally blocks etc. and once in a while you see a line like %>Welcome to XXYZY Industries!%< While this may look nicer and seem straightforward to you as a developer when you start out, often you will find that the artsy HTML people are mucking with the same files and will decide that this block of stuff on the left would look better on the right, and when the code moves with it, sometimes they will try to patch it up so it looks to them like it will still work. The result can only be described as sad.

Everyone knew from the beginning that JSP was Sun's copycat reaction to ASP, which became popular for some strange reason but is also riddled with these problems. It thoroughly mixes logic and presentation. This is OK if you're in a hurry, but if you have the time and ability to come up with something that will work better, you should just stick to servlets- which is what JSPs are pretending not to be anyway. Simplicity is a virtue.

Velocity

[jefflinwood]

Velocity makes a nice alternative to JSP for the View layer. You can plug it into Struts and use it in place of JSP, or you can embed Velocity into JSP with the Velocity JSP tag.

There's a pretty good user's guide on the Velocity web site if you want to take a look through it.

PHP and Java

[Gortbusters.org]

Might make a better team than JSP and Java. Check this out. Zend and Sun are working together on a java specification request that will interwork the easy development of PHP as a web front end to the powerful business logic systems that java provides. Sure you can do SOAP server with PHP, but that's not as good as having a SOAP server with Java (or any other sort of server) and slapping a PHP web interface on top of it. I can't wait until it's ready.

Re:PHP and Java

[ebuck]

This boggles my mind... I am trying to recover from the pain.

PHP is seldom used in an environment where there is any kind of MVC, and is often used where the logic is built directly into the web page. Java servlets can be coded to do the same, but it's an ugly, hard to maintain practice which shows the lack of design most web pages have these days. A combination (while possible) would probably bring out the worst in "slap your page together" design.

Now a few books on how to draft your page in PHP, and the refactor them into MVC structured JAVA would be divine.

Re:PHP and Java

[ebuck]

MVC - Model View Controller

The real power of MVC here is the seperation of concerns. Seperation of concerns makes the code much easier to maintain and debug, but first let's address each of the elements.

Model - The things your computer udpates, or the actual representation of whatever your program is manipulating. For example, a public (book) library system would have Books as part of their model. Books could be checked in, checked out, they have a title, one or more authors, etc.

Controller - The code responsible for updating the model, and updating the view. For example, the controller decides what the view may or may not show, what parts of the model are manipulated, and what data from the model is exposed by the view.

View - The code responsible for providing the interface to a user. For example, a view might be a web page, a text based interface, a GUI based interface, or anything else that takes the user's input and provides them with a "View" of the model's data.

By seperating the concerns, maintenance is simplified. Is the book's title wrong? It's a problem in the model. Did someone ask for something but receive something else? You have bug in the controller. Are the Book titles filling out the Author slots, well you have a problem in your View.

The problem is in most "slap it together quick, so we can roll it out the door" code, all of these concerns are placed in the same module, which creates the following problem.

If you intend to only change one aspect of the program, you run the real risk of chaning all aspects of the program.

For example, you wanted to rearrange the GUI to make it more useable, but heaven help you, because now the database connection is acting funky. How much do you know as a GUI designer about database connections? Do you want to debug it? Who knew that your connection was stored with an int counter using the ubiquitous variable i? With MVC, you can safely avoid the most common pitfalls.

Maverick

[hachete]

http://mav.sourceforge.net/

is a great MVC - *without* the hideousity of Struts et al. Simple, clean, easy - and you can even use velocity templates. It's even been ported to PHP *and* .NET

h.

Siggy played guitar, jammin' good with Weird and Gilly

Still looking for a book on modern approaches...

[eduardodude]

This book sounds pretty lame.

First, even the Struts developers themselves consider all but the struts:html tags to be obsoleted by the JSTL (lots of struts newsgroup posts to support this...no time to provide a link). JSTL provides not only a fairly rich set of "nuts and bolts" tags, but more importantly a set of base classes that can be easily extended for custom tags (such as the choose/when/otherwise construct and iterator tags). For Struts, the JSTL expression language has been encorporated into the struts-el tags, included in the latest 1.1 release. ...the caveat is that this approach requires J2EE 1.3 (Tomcat 4.0+, WebSphere 5.0+, Weblogic since forever-ago).

JSTL also obsoletes most of the Jakarta Taglib project's libraries, which frankly were very ugly from the start (separate tags for interacting with session/request/page objects? come on...check out the Expression Language that applies elegance to this problem, and is used in JavaServer Faces, JSTL, Struts-el, and everything useful from here on out).

As for templating engines, the biggest driver towards them has been the lame scriptlet-laden way JSP has historically been used (see The Problem with JSP). JSTL, Struts-el and before long JS Faces nail this problem, and IDE integration in the next year will make clear the reason why Template engines like Velocity aren't compelling (my opinion...not trying to offend).

Re:Tags?

[The Mayor]

Well, a JSP tag is simply a new HTML-like tag. When the tag is encountered in a JSP page, the servlet engine initiates the Java code that defines the tag. The goal is to separate presentation logic (i.e. HTML & coding with tags) from business logic (i.e. the Java objects behind the tags). This makes the role of separating programming (business logic, written in Java) from graphic design (HTML + custom tags).

Consider, for example, the introduction of 3 new tags: <getStudents>, <printStudent>, and <iterate>. <getStudents> performs some Java code to extract a list of all students (it's just an example...say a list of students taking a class). <printStudent> prints a single student in pretty HTML. <iterate> iterates over a list, returning a single item at a time inside of a loop. Now, it would be easy to code something that looks like:

<ecode>
<table>
<getStudents name="myStudentList">
<iterate name="myStudent" list="myStudentList">
<tr><td><printStudent name="myStudent" /></td></tr>
</iterate>
</getStudents>
</table>
</ecode>

Presumably, this allows your HTML coders the freedom of not knowing (or caring) how the list of students is made available. They could use EJBs hooked up to a 100-cpu cluster running on an app server, or they could read the list of students from a text file. The HTML coder shouldn't know or care. Meanwhile, the programmer is freed of the task of displaying the output--no need to hard-code HTML tables for formatting. With JSP + tag libraries, you can interleave custom tags with regular HTML to provide rich features in an easy to use manner.