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

Re:What about Cocoon?

[PotPieMan]

Yes, I considered mentioning AxKit and Cocoon. I haven't worked with either, so I stuck to listing the ones I have worked with.

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

[jester]

... but if you choose the XML/XSL option, be aware of the performance hit (relative to servlet/JSP) that you can take depending on your pages content.

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.

Re:Velocity

[ThatDamnMurphyGuy]

Isn't Maverick also based on Struts and Velocity?

And hot damn [Not], there's a Maverick.NET also.

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

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

Re:PHP and Java

[Anonymous Coward]

Why the hell would I want to program an app in two languages, when one does the job fine. JSP's with tags don't even need any code written in them.

I really can't see what PHP could do that is better than JSP or tags other than make the application more complex and much harder to support.

If you want to enlighten us, please go ahead.

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.

Re:PHP and Java

[version5]

This is part of Sun's new goal to evangelize Java by simplifying it, and bringing in the VB and PHP programmers. With the emphasis on JSTL and using tag libraries instead of mixing code and HTML, they are going one step further than PHP and hoping to encourage people with only HTML experience.

Unfortunately, this move might kill PHP as a serious development platform. If Java handles all the heavy lifting, will PHP will be relegated to basically writing out HTML tags? This gives PHP programmers access to a vast and robust enterprise-quality set of libraries, as well as 3rd party libraries like Jakarta Commons. The quality of the PHP libraries just isn't where it needs to be in order to support real enterprise-class applications.

The CEO of Zend claims that PHP is simply better than JSP for web development. That's completely wrong. PHP is sucessful for only one reason: Its simple. If PHP wants to get into the enterprise game, its going to end up sacrificing much of what made it good in the first place. PHP's core principles are fundamentally at odds with standard enterprise practices, since its main advantage is as a quick and dirty solution. It seems like trying to fit a square peg in a round hole, and probably driven mostly by Zend trying to create revenue rather than a grassroots movement amongst PHP developers - the general consensus seems to be "Why do we need this?"

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:ASP.Net vs JSP

[bmj]

It looks ASP.Net (Not ASP) is much more advance than JSP, as well as the development tool (VisualStudio.Net vs Netbeans).

There is some truth to that. ASP.Net has many built-in "tags" that make UI development much easier...with Java, you'd have to spend time either rolling your own taglibs, or finding open source taglibs that suite your purposes. That said, many of the ASP.Net tags are still very immature, and they don't do everything you might want -- and you're stuck with closed source, so it's harder to extend them.

VisualStudio.Net is a decent tool, though if you're running less half a gig of RAM, it'll be more frustrating than not. It is nice to be able to drag a DataTable (or whatever it's called -- it's been about 6 months ;-)) onto the screen, and set its attributes and datasource from a GUI. Very quick. But again, if you need anything more than the basic functionality, you may be in for some surprises -- it is just version 1, so I found that we were thinking ahead of what the .Net developers had included in that release. Often we found ourselves saying "That's cool, but what if we could do this..."

So I wouldn't say ASP.Net is more _advanced_ than JSPs and tag libraries....the feature set simply allows for more rapid, cookie cutter development.

Re:ASP.Net vs JSP

[molarmass192]

I wouldn't say it's more advanced, rather I'd say it includes more built-in features in the sense that VB provides more built-in features than C++. JSP is only one facet of using servlets and java for web based interfaces so it's impossible to directly compare the two. One thing we can say is that JSP allows for a much cleaner MVC implementations. ASP suffers from the same lack of separation from the user interface that VB does. Not to say that it's not possible to separate the UI from the business logic but it's definitely designed with RAD and not code reuse in mind.

Also, Netbeans is a fantastic tool for it's target market. Sure it's not as feature filled but then you're comparing a free product with a $1000+ product. If you want an apples to apples comparison, compare VS.Net to Borland JBuilder. Otherwise, you might as well be comparing MS WordPad to Corel WordPerfect.

JSP and servlet books already outdated

[toriver]

Unless they somehow manage to cover the new Servlet 2.4 and JSP 2.0 APIs. True, only the Tomcat 5.0 beta support them yet, but still...

Web and Books are not the same

[ebuck]

Although I won't comment on the usefullness of this book, I imagine that you can come up with at least 10 reasons books haven't disappeared with the invention of the web.

Let's face it, there's a lot of books which aren't much better than a collection of dispartate web pages. But how hard is it to recogonize that books and the web both provide information but to different markets due to the ways in which they can be used?

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

the big problem with Tag libs

[BigGerman]

.. is the fact that people try to make it yet another language. There are tags for (gasp) database and LDAP access, for email retrieval,etc.
What is the point of fighting MVC wars on subject of separation of the View and then load this View with logic again?
The whole idea of a JSP is to grab an Object from the request object and output its contents. The only code allowed in JSPs should be the %= obj.method() little things and simple loops to loop over the collections.
The tried-and-true architecture (what they call level 2) is to submit all the pages to the same URL (controller JSP or servlet), have it figure out what to do next, do it, load the request object with the data to be displayed and use RequestDispatcher to forward the request to JSP for display. Struts, etc does that but you do not have to use Struts, simple home-grown thing will do too.

Re:ASP.Net vs JSP

[Lysol]

Observations:

My experience over the years with other developers is that the ones who stayed text based were the ones that people came to when there were questions and issues. I've tried to make it a point over the years to stay in text land and not GUI land for the very reason that the GUI tends to dumb people down. Thusly that is the reason why I stay away from tools like Visual Studio and NetBeans.

I've worked with a lot of GUI engineers that drive the mouse a lot when you ask them a question on how this broke or that broke.
One of the best stories I know is when my friend went to work for Weblogic (pre-BEA days) and one of the engineers asked him to open a java file to look at it. He drove the mouse for a bit and then told the guy he couldn't find Visual Cafe. The engineer told him to move over and fired up Emacs and then that's what my friend used from that point on.

That said, there are a lot of good features people like in GUIs such as:

- find classes/objects as you type
- powerful searching thru code
- built-in docs
- auto code generation

However for me:
- I hate when something suggests some class while I'm typing
- find . | grep [something] works well for me
- I prefer to use the web based jdk docs as I find I learn about the classes better. Although, it's not a whole lot different than having jdk docs built in.
- code gen is good, but i don't trust machines ;)

Anyway, these are my preferences and experiences working with many engineers and I tend to find more GUI people on Win platform, which is the way that M$ want's people to develop. I choose *nix because I'd rather do it in text land and know 100% what's going on. Not the wrong way or the right way. Just another way.

Comaprison of Java based web app frameworks?

[shooz]

Has anyone done a comparison of Java based web app frameworks? The list keeps growing and it is getting harder to choose. Stuts? Cocoon? Maverick? Help?

shooz

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.

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.

Re:Anyone considering JSP should probably read...

[Brummund]

That article is written by and for Lotus Notes developers.

Allow me to quote from the article:
"Does this mean I'm against anyone ever using JSPs? If you have Domino, yes. For those who don't, JSPs can (sometimes) serve a useful role in Web application development, if you're careful."

As a side note, someone who actually says that one of the advantages with not using JSP with Domino, is that you can use LotusScript can obviously not be trusted. Have you ever had the "pleasure" of programming in LotusScript, using Domino/Notes forms? I'd rather sit in a room full of droooling Dreamweaver idiots than work on one more project using LotusScript.

Re: GUI designer

[KenSeymour]

I have yet to work on a web project that had folks that were only GUI designers.

All of our web pages were developed by developer/programmers.

By mixing scriptlets with HTML in your JSP files, everything that paints a web page is in one place.
If you have database issues, you don't have to go digging through bean code and custom tag library code to figure out why something didn't work.

We managed to meet business requirements with short duration projects.
In the large, restructuring corporation I was working in, larger projects got cancelled before they finished.

Our stuff got out and started saving them money.

When I think of MVC, I think of traditional GUI applications (either client-server or three-tier).
I don't think MVC fits as well in an HTTP get request/reply world.

YMMV.

Re:What Coldfusion as a tag library for Java?

[stretch0611]

Actually, I have used Cold Fusion for some major in-house applications and it works very well. CFML is easy to learn and quick to develop. (especially if you know HTML well.) Coldfusion integrates well with all of the major databases. It is also easy to add javascript to the code (for the few things that CFML doesn't do) and there is a product called Blue Dragon that integrates CFML with JSP at half the cost of Macromedia's Coldfusion.