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.

Re:What about Cocoon?

[Anonymous Coward]

Nobody seems to know a lot about Cocoon, but it is damned powerful. You can describe the control flow of your application in Javascript, and through the use of continuations, you can flip back and forth between states. "Eww, javascript" you say? That's fine, because only the control flow of the application is defined in Javascript. For serious business logic, you can write straight up Java objects. Additionally, Cocoon is very adamant about maintaining a strict separation between logic, data, and program flow (AKA MVC).

Other JSP books

[grennis]

A great list of other introductory JSP books can be found here...

Re:Other JSP books

[Mr. Sketch]

Some more great resources for JSP programmers looking to improve their skillset are available 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

Re:Web

[Slack0ff]

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

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.

Re:check what's there.

[Fulcrum of Evil]

if it doesn't include JSTL and JSF technologies.

Gee brain, I dunno, What's the Joint Strike Fighter have to do with Java?

Re:check what's there.

[ProfKyne]

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 cool tips and techniques ("design patterns", "best practices", whatever) for using a new technology won't even be documented until the technology is available for widespread use.

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

[PotPieMan]

I've seen plenty of servlets that do this, mostly done by people who don't know better. :-)

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

[sporty]

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

[Anonymous Coward]

Ahhh, but the poster said"
"...a servlet could generate and display HTML just as easily as a JSP could perform business logic."
[emphasis mine]
he didn't say it was smarter or less work or not ugly...
Therefore, the statement is still true.
cheers

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

[sporty]

You can compile xsl easily enough. XML, yes, it takes time to generate, but if your timing requirements isn't too intense, DOM will work fine.

Re:Servlets vs. JSP for HTML output

[JMS-Web]

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.

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.

Re:Servlets vs. JSP for HTML output

[jdhutchins]

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 page to present the results.

With JSP, it's a good idea to put almost no code in the page. The best thing to do is to write a tag that does what the code would do. It takes a little longer to write the code, but it saves time becuase it's easier to debug, and it can be used in different pages.

However, the ability to put code in JSP pages is frequently abused by people who don't know better, and that does result in mangled pages.

Re:Servlets vs. JSP for HTML output

[Anonymous Coward]

You sir, are an idiot. Please go look up model 2 mvc and repost. How can you possibly think that putting complex java and business logic into a jsp is better than using out.println()? No one uses println() anyway. Templating is where it's at...

Re:Servlets vs. JSP for HTML output

[easter1916]

To paraphrase; A long rant about mixing code and HTML in JSPs.

Good Lord. That's what tag libraries are for.

Re:Servlets vs. JSP for HTML output

[easter1916]

Who said anything about putting complex business logic in a JSP? I would use tags. I suggest you learn to read posts before responding. I am quite familiar with MVC. BTW, it's either Model 2 or MVC. Using both in a sentence is somewhat redundant.

Re:Servlets vs. JSP for HTML output

[tetsuji]

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!

Re:Servlets vs. JSP for HTML output

[jafuser]

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 up a new server.

Re:Servlets vs. JSP for HTML output

[Anonymous Coward]

Servlet is not just about println man!

Just go and check jakarta.apache.org/turbine.

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.

Re:Velocity

[Anonymous Coward]

Sorry, i use konqueror. Its a lot better then ANY of the gnome file mangagers. Oh, wait. That veloicty

Re:Velocity

[Hard_Code]

I recommend FreeMarker 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.

Re:Velocity

[plum001]

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.

Wellington L.S. da Silva is a known troll

[Gizzmonic]

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

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

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

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

[FortKnox]

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

[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

[Anonymous Coward]

An even better approach is to use javascript/ecmascript for both the user side dhtml and the server side dynamic stuff -- no switching languages or worrying. Tha't right -- asp kicks the shit out of jsp or php (which i love, but the functiona naming is a mess)

Re:PHP and Java

[Anonymous Coward]

i imagine it's like the jsp coldfusion taglibs. a transitionary tool.

Re:PHP and Java

[Anonymous Coward]

no way. i'm not letting webdevelopers near my dynamic code. we switched to only MVC frameworks two years ago. asp doesn't cut it past mom+pop sites.

Re:PHP and Java

[Gortbusters.org]

I think it'd just be PHP -> Java middle tier and elminate the web service.

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

[trompete]

Could you please define MVC for me? I'm used to it meaning Microsoft Visual C.

Re:PHP and Java

[monkeyserver.com]

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

[BigGerman]

yeah but in order to call Java from PHP in a nice platform-independent way you will have to pass XML over the wire, probably over HTTP, probably inside SOAP envelope == Web Service

Re:PHP and Java

[Gortbusters.org]

That's the point of the project, so a Java object looks like a php object to PHP.

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

[trompete]

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.

Re:PHP and Java

[ebuck]

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 pseudo-code examples.

Request Handler (Control):
doGet(request, response) {
User u = User.lookup(request.getParam(username));
if (!u.hasPermission(request.getParam(query))) { // forward the connection to a jsp "request denied page"
}
Book b = Book.getBook(request.getParam(Title), request.getParam(Author));
request.setAttribute("BookInfo", b);
RequestDispatcher dispatcher = servletContext.getRequestDispatcher("/JSP/BookDisp lay.jsp");
dispatcher.forward(request, response);
}

The Book object (Model):
{
static void initialize() {
connect to database / etc to get book info.
}

static Book getBook(title, author) {
return the correct book;
}

String getTitle() {
return title;
}
(and many other getProperty methods)
}

the JSP page (View):
{ ... html code here...
jsp:usebean id="BookInfo" class="model.Book" scope="request ... more html ...
jsp:getProperty name="BookInfo" property="title" ... more html ...
jsp:getProperty name="BookInfo" property="author" ... more html
}

It's a very simple example, and as such, does very little, but hopefully you can gather the idea of MVC seperation from my quickly constructed (aka shoddy) example.

Re:PHP and Java

[yngv]

Read the link in the review

Re:PHP and Java

[Anonymous Coward]

You *do* that.

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?"

Humor lost on Mods again

[Anonymous Coward]

sigh

Re:Humor lost on Mods again

[sulli]

so what else is new? I wear my "Troll" mods with pride.

Slashbot book review

[Anonymous Coward]

This one is a great addition to the book shelf, I know how to do certain things with JSP by using the docs, but this book clarifies nicely why you are actually doing it and provides better language specific ways of doing things that might now occur to you. Also, it introduces nice JSP concepts in a clear and easy way which scripters might not have come across before.

So Tempting...

[Line_Fault]

To start Java Bashing, or SUN bashing! Or commenting on how there are other languages that provide the same result with less effort!

Something about memory usage, overhead, xml based config files...

Maybe just promote PHP to the extent that it sounds like some nigerian spam!

Now that I got that out of that way, I hope I save some of you a lot of time! Now I'm exhausted, time for a nap!

Re:So Tempting...

[Blitzshlag]

Non-OO PHP doesnt come close to J2EE's functionality and OO PHP is an insult to the term OO.

Re:So Tempting...

[ebuck]

Dear sir,

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.

Re:So Tempting...

[Anonymous Coward]

Java is an insult to the term OO.

ASP.Net vs JSP

[nbdy]

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

[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

[Anonymous Coward]

Maybe out of the box. But on the entire playing field .NET doesn't hold a candle to Enterprise Java capability.

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.

Re:ASP.Net vs JSP

[Anonymous Coward]

if you considering zero extensibility and lack of a tag framework more advanced sure. The approach ASP.NET is different than JSP Tags. JSP tags have a set of API that anyone can implement and there's JSTL. ASP.NET uses tag-like syntax, but it is converted by the .NET framework to run on the server. Both serve achieve similar goals, but one is extensible, the other isn't. For example, you can create in ASP.Net. Atleast I haven't found a way. I could be wrong, but I don't see any base tag API in the .NET namespace for it.

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.

Re:ASP.Net vs JSP

[nbdy]

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 code behind of ASP.Net).

Re:ASP.Net vs JSP

[earache]

You write new "tags" in .NET by extending from an existing "control" or writing one based on System.Web.UI.Control.

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

[f00zbll]

It's way beyond JSP.

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 heavy loads, but it was the first commercial product that integrated a webserver with tags.

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:Maverick

[FortKnox]

hideousity of struts?

What's so hideous about struts?

Re:Maverick

[Anonymous Coward]

it doesn't hold your hand i imagine. the website is prettier.

Re:Maverick

[hachete]

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.

Re:EAT MY FUCK BITCHEZZZZ!!!!!

[Trolling4Dollars]

Oh yeah. Like THAT was an intelligent post. Like many others before you... YOU FAIL IT!!!!

Guess what? I trolled myself. :)

webapp, Java and application server security news

[Anonymous Coward]

www.cgisecurity.com

Tags

[Bame Flait]

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?

Re:Tags

[Anonymous Coward]

Custom tags fit a need before there was a standard tag library, now there is not much point.

Now its much cleaner to use a framework like struts where all of the processing code goes into a class called before the JSP is invoked and the JSP is only used to present the data.

Re:Tags

[licketyspit]

hehehe, web designers are a necessary evil. I'm glad I don't have to be the art fag that asks whether a page is visually appealing.

Re:Tags

[ebuck]

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 who would rework JSP into thier own sub-language. Encapsulating the data is the way to go, and Java Bean encapsulation seems to offer the best of both worlds. It provides a simplified tag interface for interaction with the Java Beans, and it prevents the development of various new "tag-based" JSP variants.

Re:Tags

[Anonymous Coward]

Tags are great if you want to code a block of html only once. For instance, if you have an address tag you can present the same look for an address throughout your entire system.

Your control shouldn't generate the view anyway.

[ebuck]

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 presenting. One for the receiving servlet (C) which then manipulates the Model (M) appropriately, and redirects the requests to the appropriate JSP (V) with additional information in the form of JAVA Beans.

Now you have real MVC! Your model doesn't have to control your interface, and your view cannot request data your Control servlet didn't pass along the redirect. It's many more modules to write, but each one is smaller and much easier to maintain.

too many actions?

[snatchitup]

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 have a gazillion java classes, many of which may be trivial. Not fun to manage!

The real question is... What can it do for me in the Portal environment.

Struts and Taglibs don't lend themselves well to Portal environments especially with the tendency towards CSS's to position elements. Portals don't like this.

This book is very out of date

[Anonymous Coward]

You can skip any Java JSP / Servlet book that doesn't mention JSTL. Sun finally put out a standard set of tags that do most of the stuff that people used custom tags for in the first place.

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

cheaper

[Anonymous Coward]

Amazon has it cheaper via the marketplace sellers.

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?

Re:Why so many J** acronym reviews?

[Anonymous Coward]

One less blindly pro-Java moderator point.
How do you like the fact that Java has become a commodity?
Hope you like low paying entry-level work.

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:the big problem with Tag libs

[licketyspit]

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 being displayed, they send me the corrected html tags for displaying and I make the changes.

Re:the big problem with Tag libs

[licketyspit]

ack I import the template...

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:Comaprison of Java based web app frameworks?

[jafuser]

Isn't it great to have so many standards to choose from?

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

wonders of /. moderation

[Anonymous Coward]

1. the guy describes this thing 2. bunch of others reply how stupid this idea is 3. the guy moderated Insightful

Tags?

[jpkunst]

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?

[SkjeggApe]

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 webdesigner will like this better than writing:

<%
String username = (session.getAttribute("UserName") == null ? "Guest" : "" +session.getAttribute("UserName"));
for(int i=0;i<2;i++){ %>
Hello <%=username %>!
<%}%>

Of course, outputting "Hello joe!" twice is silly, but that decision is (usually) up to the designer.
This really pays off when at some point, you for example would like to not store the username as a String in the session, but maybe put it in some other scope, or maybe you now have a User object in the session scope, so session.getAttribute("UserName") won't work. The developer can make these changes on the backend, and the designer would never need to know.
Also, maybe the designer now realizes that is's dumb to show the output twice, but isn't comfortable modifying the "magic coding stuff" in the for loop, and therefore decides to ask you to do it, whereas with the custom tag he might be able to figure it out himself, leaving you to read slashdot in peace.

All errors (if any) are made on purpose. Yes, I do have a reason why, and no I won't tell you what that reason might be.

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.

What Coldfusion as a tag library for Java?

[Anonymous Coward]

I know that the CFML platform is often associated with simple, design-friendly web apps (e.g. intranets) but now that it is written atop Java (or J2EE) - it seems pretty attractive. One can't deny the elegance & ease-of-use of the CF markup language.

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.

Re:What Coldfusion as a tag library for Java?

[booms]

Why mess with Bluedragon when its got known bugs such as not escaping quotes in queries (PDF File), etc.? As for me, I'd rather install CFMX J2EE on Tomcat. Actually, I do have CFMX running on FreeBSD now, and it works pretty well other than me still trying to get it to run as a non-root user.

- Brandon

Re:What Coldfusion as a tag library for Java?

[stretch0611]

Actually, according to the same PDF file you mentioned, Blue Dragon will escape quotes for values placed in CFQUERYPARAM tags.

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.

Re:Why so many J** acronym reviews?

[Anonymous Coward]

$86K for basic Java development suits me fine, thanks.

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

[ebuck]

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 and footer, then the controller (which manipulates both the model AND the view) should pass the info along in a Java Bean. That would allow the header and footer to grab the title without the fear of "missing a semicolon" using the normal JSP bean extensions.

Some of their work is interesting, and I like the bit about loops, but a lot of it implys that they are complaining about badly coded JSP pages. I mean, a 30K JSP page? Only if you don't have any MVC, and inline the JSP at every opportunity.

Bah

[CausticWindow]

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

[andbutso]

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

[Putte]

Yes

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.

Anyone considering JSP should probably read...

[release7]

JSP is probably not the way to go in the first place. This informative article, JSP: A Total Waste of Time? sums up some of the core problems pretty nicely.

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.

What a lame subject

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

Just be a good architect, analyse the situation, and choose the right set of tools.

Hasta la vista.

JSP et al ...

[Anonymous Coward]

JSP = theoretical experiment gone awry.

Let's bury it and move on to more commercial available techniques?

A good learning tool, but ... What? Pascal?

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

[orionware]

What I see alot are companies spending twice what they need to be spending because they get "sold" on either .NET or JSP.

Hell. We'll take their money and give them what they want if they are stuck on a technology they know nothing about other than the "buzziness" of the acronym.

Usually we will push a client toward Coldfusion MX as an alternative. It's what .NET is trying to become in the worst way. Coldfusion MX is built on top of java and will run on JRun, Websphere and several flavours.

The development time is drastically cut in CFMX and it's just as capable with web services, SOAP and all the other goodies.

Re: GUI designer

[Anonymous Coward]

OK genius. Let's say you need to call the business logic you've just embedded in 3 or 4 jsps without presenting a user interface. You know, something like a batch process. What are you going to do? You're going to have to rewrite the business logic elsewhere, that's what you are going to do. Now you're screwed because you're business logic is in more than 1 place.

Re:Why so many J** acronym reviews?

[Anonymous Coward]

Not for long. You'll be layed off soon and someone rehired at half that rate, as is the fashion in the industry right now. Take a look at the new Java job postings' salaries. Not pretty.

Have you Tried ASP.NET ?

[Anonymous Coward]

Asp.Net is the best thing since slice bread. Your page and your code are the same. None of this, jsp page which is part java, part html, part your business logic and then pass the info to a servlet.

Why band-aid on top of band-aid.

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

[Anonymous Coward]

Hmmm. But Velocity was built up BEFORE JSTL. And JSTL just tries to repare JSP problems. Velocity on the other side is neat, clean and fast. Just Give it a try to be convinced :-)

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

[Anonymous Coward]

i tried it. it makes things simple but hamstrings you. i need to use 3rd party taglibs too...

sorry the future just don't look good for it.

How about tag library design?

[Anonymous Coward]

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

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

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

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

Any comments?

Jackson Structured Programming

[wolverine1999]

I thought JSP referred to Jackson Structured Programming... A different JSP used in software development.

Re: GUI designer

[tetsuji]

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 difficult to change that it has basically had to be entirely rewritten in-house.

The real beauty of using MVC in a web application is flexibility. There's a lot of functionality that is common to numerous pages in most websites, and to avoid code duplication by using JSP includes has to be one of the messiest and most dangerous things I can think of. If multiple developers are working on the project you end up with all kinds of issues with names stepping on one another, unsatisfied dependencies, etc.

An MVC architecture is essential to any web application with any degree of complexity.