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?

Re:What about Cocoon?

[ThatDamnMurphyGuy]

Forgot the link to Cocoon Cocoon

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

[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.

Wellington L.S. da Silva is a known troll

[Gizzmonic]

Don't trust him! He goes on Usenet all the time and he dynamically amalgamates posts about Java servlets and HTTP, passing the comments out for his own.

Sad that this hack actually got a book deal(!). The truth is, I've met Wellington...he's actually a nice man. He lives in Mombasa, and he's happiest when he's on safari. He really fills out field khakis and a pith helmet, let me tell you...

But if you ever see him on USENET, beware! His foppish charm doth not extend to the virtual realm.

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

Re:PHP and Java

[BigGerman]

I dont think this is going to fly.
The current trend is to move as much as possible into the same JVM (JSPs, middle tier, db access) instead of further separating the tiers (as PHP -> Web service -> Java middle tier would require).

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

Re:Still looking for a book on modern approaches..

[bzhou]

For modern approaches, you'll have to look outside of the java box. From the language/devel environment that brings us MVC, there's Seaside. Similar continuation-based approach is used more in the Lisp/Scheme community. On java platform, Coccon Control Flow also uses continuation.

I don't believe there's any book on those yet.

How about tag library design?

[Anonymous Coward]

Since inception, it seems majority of efforts of developers, and unfortunately, authors too, have been on explanation and usage of tag libraries - the tags, the EL and RT, etc. Admittedly, books on tag libraries go a step further these days and talk about taglib frameworks, like JSTL or Struts Tiles, or Cocoon (don't flame me please if i missed your favorite) and as mentioned, the segments on these frameworks tend to read more like the readme's on the websites of these frameworks - probably because the framework authors/developers spent a lot of time ensuring the framework was documented well enough for the users to be able to glean the benefits and use them!

However, there is even greater issue with taglibs that I feel goes unheeded usually. That of a taglib design. As a set, the taglibs tag form a language: the syntax is defined by the jsp spec to be XML, the elements are defined by the tag author and constrained by the taglib DTD, and the semantics (or actions) are provided by the library. So, in essence, when you create a tag library you are create a new language. I agree, in most cases, this new language will be used by the author himself (or herself), and hence little attention is paid to the semantics of the language. But, alike library/api development, with web-applications outliving their foreseen life, quite often one comes across taglibs written by others - and that's when one begins to realize the follies.

Has anyone come across or formulated a strategy for tag library design?
How does one determine the interfacing between the view helpers (or related server-side components) and tag libraries?
What problems does one encounter in tag library extensibility and customization?
What would be the potential pitfalls to watch out far?

Toting forth the vision heralded by JSP technology authors, taglibs form one of the several components, that put together, vie to separate the presentation logic from the business logic. However, I believe that last statement needs to be refactored further. We also need to separate presentation logic from view generation logic - so that the web page designers can truly create web pages without having to worry about where the script elements will be placed - so, in essence, the tag library authors will provide tags that will read like HTML (now that would be one guideline i suppose - design tag libraries on the concept of a declarative language), and the tag (or at least most of them), will be smart enough to wrap trivial expressions (the usual scriptlets to set a particular variable to calculate the colspan, for example).

Any comments?