Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

JSP and Tag Libraries for Web Development 136

Posted by timothy from the tag-that-sucker dept.
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
    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
    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
    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.
This discussion has been archived. No new comments can be posted.

JSP and Tag Libraries for Web Development More

JSP and Tag Libraries for Web Development

Comments Filter:

  • What about Cocoon? (Score:4, Interesting)

    by ThatDamnMurphyGuy ( 109869 ) on Tuesday July 08, 2003 @11:54AM (#6392205) Homepage
    Not to mention AxKit [axkit.org] in those lists of templating systems?

  • Other JSP books (Score:5, Informative)

    by grennis ( 344262 ) on Tuesday July 08, 2003 @11:54AM (#6392207)
    A great list of other introductory JSP books can be found here [geocities.com]...

  • Web (Score:4, Insightful)

    by Slack0ff ( 590042 ) <[matbrady] [at] [bored.com]> on Tuesday July 08, 2003 @11:55AM (#6392221)
    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 (Score:3, Informative)

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

    • Re:Web (Score:3, Insightful)

      by gfxguy ( 98788 )
      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 (Score:3, Interesting)

      by redJag ( 662818 )
      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
      • Very true I have linux books lining a shelf and it makes me feel good to look at them. But truthfully I use websites/usenet/other message boards for when I really have a problem (Only I can crash linux as many times as I do. Somthing about my tendancy for logical fallacies and C++.
    • 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?

  • check what's there. (Score:4, Insightful)

    by Anonymous Coward on Tuesday July 08, 2003 @11:56AM (#6392230)
    if it doesn't include JSTL and JSF technologies.

    DON'T BUY IT!

    This book looks seriously out of date.

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

    by easter1916 ( 452058 ) on Tuesday July 08, 2003 @11:56AM (#6392232) Homepage
    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!
    • I've seen plenty of servlets that do this, mostly done by people who don't know better. :-)
    • 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.
    • Or (to give a plug), use a template engine, like freemarker or stxx which uses xml output to xslt stylesheets. http://stxx.sourceforge.net

    • Re:Servlets vs. JSP for HTML output (Score:5, Insightful)

      by jester ( 8414 ) on Tuesday July 08, 2003 @12:38PM (#6392662)
      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 [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.

      • You Wrote:

        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.

        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.

    • Anyone performing this kind of development forgot a key aspect of designing their servlet/JSP. MVC gets bandied about again and again as the thing to do, but most of the servlets I've seen have nothing to do with MVC.

      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)

      by MillionthMonkey ( 240664 ) on Tuesday July 08, 2003 @01:06PM (#6392960)
      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.

      • JSP and Servlets are complimentary, as said before. It's much much easier to put business logic inside a servlet. However, even if you're doing something other than out.println() in a servlet, making the HTML is still awkward, and much more difficult to change around. The other disadvantage is that it's quite difficult to quickly glance through the code and see what the page is going to produce.

        Servlets should be used for things like handling form submissions, and then they should pass it on to a JSP pa
        • What I like about doing logic inside a .jsp is that I don't need to go configure the web.xml or other .conf files just to add more pages to the website. The server picks up the .jsp and figures it's mapping out on it's own.

          Besides, is there really any disadvantage to using one .jsp for the controller which forwards to another .jsp for the view?

          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
      • To paraphrase; A long rant about mixing code and HTML in JSPs.
        Good Lord. That's what tag libraries are for.
        • My thoughts exactly. Whoever wrote that post was thinking about the state of JSP's a few years ago.

          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!

  • Velocity (Score:5, Informative)

    by jefflinwood ( 20955 ) on Tuesday July 08, 2003 @12:00PM (#6392278) Homepage
    Velocity [apache.org] 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 (Score:2, Informative)

      by ThatDamnMurphyGuy ( 109869 )
      Isn't Maverick [sourceforge.net] also based on Struts and Velocity?

      And hot damn [Not], there's a Maverick.NET also.
    • I recommend FreeMarker [sourceforge.net] over Velocity. Although it is more strictly typed (this can be a good or a bad thing depending on who you are), it preparses templates (IIRC), and it can also do really great things like recursive macros.
    • I agree with these posts. After spending several years doing Servlet/JSP pages and designs I have concluded that they still take too much time to develop. Template engines like Velocity and FreeMarker are a much better solution to keep presentation and coding elements separate. JPublish is another good framework that helps you organize Velocity or FreeMarker pages.
  • 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.

  • PHP and Java (Score:5, Insightful)

    by Gortbusters.org ( 637314 ) on Tuesday July 08, 2003 @12:08PM (#6392360) Homepage Journal
    Might make a better team than JSP and Java. Check this out [zend.com]. 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.
    • With struts and taglibs, I can't say that PHP would make it any prettier.

      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)

      by BigGerman ( 541312 )
      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 (Score:2, Insightful)

      by 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 (Score:5, Insightful)

      by ebuck ( 585470 ) on Tuesday July 08, 2003 @12:56PM (#6392866)
      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.
      • Could you please define MVC for me? I'm used to it meaning Microsoft Visual C.
        • Please read the review before asking questions:

          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)

          by ebuck ( 585470 ) on Tuesday July 08, 2003 @02:06PM (#6393603)
          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.
          • Thank you. That was very helpful. I've never really looked at code that way before. I'd like to see a working example of the practical separation of the MVC components.
            • If you mean a pratical working example, odds are you are already using one. MVC is used heavily in well designed (NOT VB) gui applications like window managers, or GUI toolkits. Unfortunatly Visual Basic teaches the world not to design the application, but rather to draw the interface, and then hang code off of it's events. As a result you typically see the handler methods grow in size and complexity as they have to handle the model, view and controller.

              For a mini-demo, let me present the following pseu

          • Re: GUI designer (Score:2, Insightful)

            by KenSeymour ( 81018 )
            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
            • Hold on a second there, Bub.

              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:3, Insightful)

      by version5 ( 540999 )
      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

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

    • Re:ASP.Net vs JSP (Score:3, Insightful)

      by bmj ( 230572 )

      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

      • Exactly, I guess Sun has been working toward the VS.Net approach now. I don't know if J-Builder will easy the rapid development. I used VS.Net and the "tags/web controls" works fine. I agree to extend the control is not easier especially when some attributes were pre-defined private (Like Borland Delphi/C++ Builder). However in the most cases the controls are good enough. I am eager to looking forward the new development tools for JSP with a lot of built-in tags and a clear seperated code and UI (like the
    • 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 bu

    • Re:ASP.Net vs JSP (Score:3, Insightful)

      by Lysol ( 11150 )
      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

  • Maverick (Score:3, Interesting)

    by hachete ( 473378 ) on Tuesday July 08, 2003 @12:24PM (#6392520) Homepage Journal
    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
    • hideousity of struts?

      What's so hideous about struts?
      • I dropped a struts implementation in favour of maverick purely on the basis that maverick gave me ease of use for configuration (faster time from idea-to-implementation) plus choice of templates. And the website is prettier.

        h.
  • Maybe some other people can comment on this, but I find tags a needless amount of work in servlet-oriented systems.

    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?
    • I have to agree.

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

    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)

    by toriver ( 11308 ) on Tuesday July 08, 2003 @01:03PM (#6392925)
    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...

  • Still looking for a book on modern approaches... (Score:4, Informative)

    by eduardodude ( 122967 ) on Tuesday July 08, 2003 @01:28PM (#6393161) Homepage
    This book sounds pretty lame.

    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. ...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 [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).
    • Try "Bitter Java" by Manning. I'm not saying that it has anything much better than a call to return to MVC, but it's written well, and it's code seems to be sanity-checked.

      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
    • 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 [beta4.com]. Similar continuation-based approach is used more in the Lisp/Scheme community. On java platform, Coccon Control Flow [apache.org] also uses continuation.

      I don't believe there's any book on those yet.
  • .. 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
    • I second this emotion. When you have to all of a sudden learn a third language just to use taglibs, the functionality gains are quickly lost. While I entirely agree with the above said, I don't often simplify the jsp to just one object. More often than not I force the designer to create a template and just or it into the jsp, which allows the the core logic to take up the majority of the jsp and keeps the overall look of the page up to the designers whims. If they don't like the aesthetics of the data
  • 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

  • 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

    • It's very similar to a html tag, except that the server processes it insted of the browser. For example, the

      <h1>

      tag tells the browser that text within it should be large and bold, whereas some simple, made-up custom tags could be something like:

      <loopoverthis times="2">
      Hello <printsomething what="UserName"/>!
      </loopoverthis>

      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)

      by The Mayor ( 6048 ) on Tuesday July 08, 2003 @03:58PM (#6394799)
      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.

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

  • a book for JSP developers wanting to improve their 'skillset.'

    Why coding in Java is a bad idea:
    Makes you use terms like "skillset"

  • JSP is probably not the way to go in the first place. This informative article, JSP: A Total Waste of Time? [advisor.com] sums up some of the core problems pretty nicely.
    • 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,

  • What a lame subject (Score:1, Informative)

    by Anonymous Coward
    Again I stare at a lame subject with surprise: what is such a subject doing in the front page of (gasp) almighty Slashdot?

    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)

    by 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 fram
  • I thought JSP referred to Jackson Structured Programming... A different JSP used in software development.

Slashdot Top Deals

Hackers are just a migratory lifeform with a tropism for computers.

Close