Slashdot Mirror
JSP and Tag Libraries for Web Development
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- Understanding the Tag Library Extension API
- Introduction to Servlets and JavaServer Pages
- Introduction to Tag Libraries
- Writing Custom Tags
- Cooperating Tags and Validation
- Design Considerations
- The Struts Framework
- The Jakarta Struts Project
- Struts Tag Libraries
- Anatomy of a Struts Application
- The Jakarta Taglibs and Other Resources
- The Jakarta Taglibs Project
- Commercial Tag Libraries
- Other Resources
- Appendices
- Tomcat
- Allaire JRun
- Orion
- MySQL
- Mapping Servlet-JSP Objects
- 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.
A great list of other introductory JSP books can be found here...
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.
Tips and Tricks for Mozilla
I was referring primarily to the documentation available on the Struts site. Their user guide and taglib documentation is generally very good.
Yes, I considered mentioning AxKit and Cocoon. I haven't worked with either, so I stuck to listing the ones I have worked with.
... 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.
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...
This book sounds pretty lame.
...the caveat is that this approach requires J2EE 1.3 (Tomcat 4.0+, WebSphere 5.0+, Weblogic since forever-ago).
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.
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).
.. 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.
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.
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.
Again I stare at a lame subject with surprise: what is such a subject doing in the front page of (gasp) almighty Slashdot?
.net as well, as asp.net has some very good set of tools. I would qualify asp.net as a combination of jsp/servlets + standard tag libs + templating. It has some caveats as using page controller pattern and too much ado.net placed directed in a page. But better than pure jsp/servlets. PHP is good for Personal Home Pages, period. Those big sites using it are having a pretty bad maintenance time (or will have soon). Zope is not general enough, but good enough for simple content managing. Maybe OpenCMS will catch up one day. Ruby? Doesn't counts for serious enterprise level applications. Bashing EJBs is not productive either, there are several situation where EJBs fit nicely, and dozen other that don't.
C'mon. This book is so old my grandma used to read it in elementary school.
Slashdot homepage is for really geeky subjects like new mathematical milestones, brand new technology reviews, (bashing microsoft & cia), etc.
And this subject was already so discussed: Pure J2EE Web support is pretty lame in the current version. JSP/Servlets are almost like having to build a rich application without AWT or Swing (using Graphics to draw lines and squares by hand).
Every single developer knows (or at least, has the obligation to know by now) that you just have to combine J2EE with some other framework. The basic toolset being Struts (workflow) + Validator + Tiles/JSTL (view templating) + Hibernate (persistence).
Every single developer knows (or should know) that one must never ever place database logic in a JSP page even through tag libs. One should always use some kind of persistence layer, any one (Hibernate, JDO, Entity Beans, whatever).
Every single developer knows that the best pattern is to avoid page controllers and use the front controller approach.
Every single developer knows that a serious web site must use templating, any one, be it cocoon, tiles, velocity, whatever.
This is so basic I don't even know why I'm wasting my time writing obvious facts. Anyway.
Ok, so someone doesn't know (so why are you calling yourself a "developer"?). Well, the web is full of resources so there's no excuse to not know something. And instead of bashing every single microsoft move, one would be smarter to know
Just be a good architect, analyse the situation, and choose the right set of tools.
Hasta la vista.
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.
Looking for a job?
Want your resume written professionally?
DON'T USE TUNAREZ!!!