





JSP and Tag Libraries for Web Development 136
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
- 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.
What about Cocoon? (Score:4, Interesting)
Re:What about Cocoon? (Score:2, Interesting)
Re:What about Cocoon? (Score:2, Informative)
Other JSP books (Score:5, Informative)
Re:Other JSP books (Score:2, Informative)
Web (Score:4, Insightful)
Re:Web (Score:3, Informative)
Re:Web (Score:3, Insightful)
Re:Web (Score:3, Interesting)
Re:Web (Score:1)
Web and Books are not the same (Score:3, Insightful)
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?
check what's there. (Score:4, Insightful)
DON'T BUY IT!
This book looks seriously out of date.
Re:check what's there. (Score:2)
This book looks seriously out of date.
The reviewer mentions this in the review. The actual copyright date is 2001. You can't fault this book for not having JSF coverage. Also, what good is JSF coverage when there's no production-ready JSF implementation (not even the RI) available yet? If I'm going to buy a book today on JSP and servlet development, I'd rather have useful information about what is available now than projections of how things are supposed to be in a few months. Especially since the c
Servlets vs. JSP for HTML output (Score:3, Interesting)
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 (Score:1)
Re:Servlets vs. JSP for HTML output (Score:3, Interesting)
The whole "view in MVC" discussion is way above the level of average developer.
Re:Servlets vs. JSP for HTML output (Score:2)
Re:Servlets vs. JSP for HTML output (Score:2, Informative)
Re:Servlets vs. JSP for HTML output (Score:2)
Re:Servlets vs. JSP for HTML output (Score:5, Insightful)
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 [ajsoft.net] 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 (Score:1)
Really?
What happens when you're the "only" developer in an organization that outsourced a project you are supposed to customize and you're unsure of the best method to utilize?
HHmmmm... inquiring minds want to know.
I prefer to use the JSP as I'm more familiar with the HTML than the Java angle.
Your control shouldn't generate the view anyway. (Score:2)
If you want real MVC, your servlet which receives the request would be considered the Control (C) as such, it shouldn't have any System.out.println(...) requests in it at all. That would be part of the View (V).
A much better solution is to write 3 modules for each web page you are presentin
Re:Servlets vs. JSP for HTML output (Score:4, Interesting)
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.
Re:Servlets vs. JSP for HTML output (Score:1)
Servlets should be used for things like handling form submissions, and then they should pass it on to a JSP pa
Re:Servlets vs. JSP for HTML output (Score:2)
Besides, is there really any disadvantage to using one
It's a lot less of a hassle than having to remember to configure the servlet and servlet-mapping directives in the web.xml for *all* the servlets, every time I set
Re:Servlets vs. JSP for HTML output (Score:1)
Re:Servlets vs. JSP for HTML output (Score:1)
These days, it seems like things change too fast in this industry to be able to even compare competing technologies effectively, because by the time you've fully learned and understood the capabilities of one system, the competing systems have advanced enough that catching up would take long enough to put you behind the times with the system you know!
Re:Servlets vs. JSP for HTML output (Score:1)
Velocity (Score:5, Informative)
There's a pretty good user's guide on the Velocity web site if you want to take a look through it.
Re:Velocity (Score:2, Informative)
And hot damn [Not], there's a Maverick.NET also.
Re:Velocity (Score:2)
Re:Velocity (Score:1)
Wellington L.S. da Silva is a known troll (Score:1, Interesting)
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.
PHP and Java (Score:5, Insightful)
Re:PHP and Java (Score:1)
When I get time tonight, I'll write up a webpage in a bunch of different languages to show off the 'prettiness' of struts on a jsp.
Re:PHP and Java (Score:2, Interesting)
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 (Score:2)
Re:PHP and Java (Score:1)
Re:PHP and Java (Score:2)
Re:PHP and Java (Score:2, Insightful)
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 (Score:5, Insightful)
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 (Score:1)
Re:PHP and Java (Score:1, Flamebait)
The Model 2 architecture, based on Smalltalk's Model-View-Controller (MVC) design pattern, showed that servlets and JSPs complemented each other.
Re:PHP and Java (Score:5, Informative)
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 (Score:1)
Re:PHP and Java (Score:2)
For a mini-demo, let me present the following pseu
Re: GUI designer (Score:2, Insightful)
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
Re: GUI designer (Score:1)
In a complex application, the amount of code that is required to go into scriptlets can quickly dwarf the amount of presentation layer stuff. I regularly have to deal with JSP files that are 3000+ lines of mangled Java, HTML and JavaScript that was written in this fashion by a consulting firm for the government. The application is supposed to be a powerful metadata management toolset for satellite datasets, but the way it was written has caused it to be so inflexible and diffic
Re:PHP and Java (Score:1)
Re:PHP and Java (Score:3, Insightful)
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
Re:So Tempting... (Score:1)
Re:So Tempting... (Score:2)
Due to hostile conditions at my current work place, and probing inquiries by the w3c concerning our HTML tagging, we are unable to discreetly move a large number of web pages to a remote server co-located in eastern Tenessee.
This represents an opportunity for yourself as these web pages are desperately needed by private developers of our internal web site who are having difficulty without their Frontpage web instruction....
I couldn't finish, it started to sound too true.
ASP.Net vs JSP (Score:1)
Re:ASP.Net vs JSP (Score:3, Insightful)
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 harde
Re:ASP.Net vs JSP (Score:1)
Re:ASP.Net vs JSP (Score:3, Insightful)
Re:ASP.Net vs JSP (Score:3, Insightful)
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
Re:ASP.Net vs JSP (Score:1)
The design is similar to what one would do in writing standard UI controls for desktop applications. Furthermore there is support for templating, child controls, etc.
It's way beyond JSP.
Re:ASP.Net vs JSP (Score:1)
I fail to see how it is way superior. Different yes, but superior reveals your bias. You can extend the Control class right, but AC is right if API meant interface. My personal preference would be to have a base interface, which Control implements. This way I can use some other custom underlying widget, rather than the default look. And, lets remember that cold fusion probably is the first one to use tag-like syntax for server side controls. cold fusion had a terrible time scaling for
Maverick (Score:3, Interesting)
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*
h.
Siggy played guitar, jammin' good with Weird and Gilly
Re:Maverick (Score:2)
What's so hideous about struts?
Re:Maverick (Score:1)
h.
Tags (Score:1)
If you have a tag that you're using to operate on some data before presenting it, why not encapsulate that data in an object (which it probably already is) and make it a method?
I have a better solution, though - how about dumbass web "designers" who don't know jack about programming go back to their worthless design schools and munch on my choad?
Re:Tags (Score:2)
After enought tags accumulate, you need to standardize on them, which usually results in a bit of bickering over what tag does X better.
Eventually all of your JSP pages become "Tag platform X" specific, requiring anyone else using the "enhanced" JSP environment to be careful about the introduction of new tags. As a final blow new developers will have no idea that tag FOO exists, and will have to be brought up to speed on your flavor of JSP.
All in all, tags seem to be the tool of those wh
too many actions? (Score:2)
Well, if you've ever worked on a moderate to large scale system, you realize you're going to ha
JSP and servlet books already outdated (Score:3, Informative)
Still looking for a book on modern approaches... (Score:4, Informative)
First, even the Struts developers themselves consider all but the struts:html tags to be obsoleted by the JSTL [apache.org] (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 [apache.org] that applies elegance to this problem, and is used in JavaServer Faces [sun.com], 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 [servlets.com]). 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:Still looking for a book on modern approaches.. (Score:2)
I checked out the "Problem with JSP" site, and many of the issues it raises are present in "Bitter Java". I don't agree that the JAVA bean tags are fundamentally worse (or better) than the alternative syntax templating provides, but the last example (manipulating the title) is a cop-out.
If the title is supposed to change in the header
Re:Still looking for a book on modern approaches.. (Score:2, Interesting)
I don't believe there's any book on those yet.
the big problem with Tag libs (Score:2, Informative)
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
Re:the big problem with Tag libs (Score:1, Informative)
Comaprison of Java based web app frameworks? (Score:2, Insightful)
shooz
Re:Comaprison of Java based web app frameworks? (Score:2)
I'm laying low until something prevails. Struts seems to be top on my list to invest some reading time in (whenever I finally get some time)...
Tags? (Score:2)
I've never used JSP and I'm wondering: could someone explain (or point to an explanation of) what a tag means in this JSP/Tag Libraries context? I only understand (from the context) that it's probably not "tag" as in "HTML tag", but that's about it.
Thanks in advance.
JP
Re:Tags? (Score:1)
tag tells the browser that text within it should be large and bold, whereas some simple, made-up custom tags could be something like:
The server will process the tags,perhaps outputting something like:
Hello joe!Hello joe!
or perhaps:
Hello Guest!Hello Guest!
The theory being that a we
Re:Tags? (Score:4, Insightful)
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"
</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.
Bah (Score:2)
Don't waste your time on Tag libs. The whole point of templating and abstraction is to remove the logic from the presentation. Tag libs is going the other way.
Lingo (Score:1)
a book for JSP developers wanting to improve their 'skillset.'
Why coding in Java is a bad idea:
Makes you use terms like "skillset"
Re:Lingo (Score:1)
Anyone considering JSP should probably read... (Score:2)
Re:Anyone considering JSP should probably read... (Score:3, Informative)
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,
What a lame subject (Score:1, Informative)
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 applicatio
How about tag library design? (Score:1, Interesting)
Jackson Structured Programming (Score:1)
Re:Humor lost on Mods again (Score:1, Offtopic)
Re:EAT MY FUCK BITCHEZZZZ!!!!! (Score:1, Offtopic)
Guess what? I trolled myself.
Re:What Coldfusion as a tag library for Java? (Score:3, Informative)
Re:What Coldfusion as a tag library for Java? (Score:1)
- Brandon
Re:What Coldfusion as a tag library for Java? (Score:2)
One a the reasons I enjoy Blue Dragon is the license allows for free development use. Admittedly, it is only compatable with CF 5.0 tags, but that is all we use in the office; we currently do not have a compelling reason to upgrade to CFMX.