This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes JSP and the fly likes Uses for JSTL SQL tags? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » JSP
Bookmark "Uses for JSTL SQL tags?" Watch "Uses for JSTL SQL tags?" New topic
Author

Uses for JSTL SQL tags?

John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1441
Hi, all!
The one thing that has really concerned me about JSTL is the inclusion of the SQL tags. I really don't like the idea of a JSP going directly to the database and would prefer to have a layer that abstracts the DB from the presentation.
The people who developed JSTL thought there was a need for these tags, though. So, can anyone provide justification and/or examples where using these tags would be preferred to an N-tier approach (other than the ones briefly mentioned in the spec)?


The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
Shawn Bayern
Author
Ranch Hand

Joined: May 06, 2002
Posts: 160
Originally posted by John Wetherbie:
Hi, all!
The one thing that has really concerned me about JSTL is the inclusion of the SQL tags. I really don't like the idea of a JSP going directly to the database and would prefer to have a layer that abstracts the DB from the presentation.
The people who developed JSTL thought there was a need for these tags, though. So, can anyone provide justification and/or examples where using these tags would be preferred to an N-tier approach (other than the ones briefly mentioned in the spec)?

Actually, on this particular point, the expert group thought it was more helpful to provide a standard in a widely divergent area than to be dogmatic about a particular model of web development. So there aren't too many other expected uses than those suggested in the spec.
The SQL tags are intended primarily for small applications, or those where there's a single programmer and in which multiple layers would be too cumbersome.
As an example, a widely known proponent of MVC once told me that there are many things he wouldn't use MVC for; for instance, he said that a guest book would be too small to be worth multiple layers. If you want to add a simple counter or guest book to your site, it might be easier to write a single <sql:update> or <sql:query> tag and then forget about it, rather than to construct and maintain appropriate beans.
Still, "model 2" is an extremely sound model, and in medium-sized or larger applications, JSTL's SQL tags aren't expected to be necessary. Instead, the expectation is that the data would be sent to core tags like <c:forEach> and <cut>, and that JDBC ResultSets would be converted into JSTL "Result" objects. Thus, JSTL's API is still useful even to the largest and most demanding applications (though for extremely large result sets, the caching that JSTL Result objects provide might be a bit memory intensive).


Shawn Bayern<br />"JSTL in Action" <a href="http://www.jstlbook.com" target="_blank" rel="nofollow">http://www.jstlbook.com</a>
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1441
OK, that sounds reasonable. Using the methaphor (or analogy) of a toolbox, you provided some tools, the SQL tags, that can be used in certain situations. It is up to the user to make appropriate use of the tool.
So, if you had a Struts based website (or some other framework/library) do you think using an SQL tag for a guest book, or other small items, would outweigh using the framework to provide a consistent approach to DB access throughout the application?
Shawn Bayern
Author
Ranch Hand

Joined: May 06, 2002
Posts: 160
Originally posted by John Wetherbie:
So, if you had a Struts based website (or some other framework/library) do you think using an SQL tag for a guest book, or other small items, would outweigh using the framework to provide a consistent approach to DB access throughout the application?

Great question. It could, but it depends on a number of things. For instance, if my guestbook data were stored in the same database, with the same DataSource, as the rest of the application's data, it would be convenient to use existing beans, pools, and patterns. But suppose I've got a banking application with a secure database and then a little, one-off MySQL database that stores the user's color preferences, or other things related entirely to display. (Or perhaps, going back to the old example, suppose I want to add a simple hit counter, guestbook, or trivial survey.) It might be easier to add these things in JSTL, since they aren't tied to any real "model" -- that is, any data that's actually important to the purpose of the application.
As always, it's a judgment call. You might decide that the surveys are important enough to cut reports to management and use on a number of different sites run by the same company; past a certain point, it becomes valuable to abstract and reuse logic, which is, after all, one of the main goals of any patterns-based approach, including MVC.
But you're absolutely right to say that the goal of JSTL was to provide tools for different situations and to leave design decisions to designers in the field. And even if you don't use the SQL tags because you find it more convenient to abstract logic behind a bean or framework, you might find the SQL tags useful for prototyping as well. (That is, when you do a quick mock-up, you might code several pages that contain just SQL tags, and then replace this with a servlet. Certain MVC controllers are so trivial, especially in the prototyping phase of some applications, that building them with a handful of JSTL SQL tags and JSTL <c:import> and <c:redirect> tags gets you a long way. I don't typically recommend this for large applications, but it's an option.)
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1441
Ah, interesting. I remember the spec mentioning prototyping.
Does your book use this as an example? I could see a little case study - here's a prototype and then here's the full up approach with a servlet, etc.
Sorry, don't mean to put words in your book...
James Carman
Ranch Hand

Joined: Feb 20, 2001
Posts: 580
Sometimes I find that using the MVC framework for simple query displays does seem to be overkill. I think the SQL tags included with the standard tag library are nice. The only drawback I can see is that the entire result set is cached into memory (embodied as a javax.servlet.jsp.jstl.sql.Result object) as opposed to streaming the result set back as needed. I realize that there are startRow and maxRows attributes on the query tag, but what if I really want to show a large number of results (say 1000) on my page? I would rather not cache all of those results in memory first and then output them.


James Carman, President<br />Carman Consulting, Inc.
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1441
Good point about large result sets. What we have done to handle this problem is trade off database hits for memory, that is, we only get enough to display on one page and when the user wants to see more of the data we hit the DB to get the data to be displayed. Otherwise the memory requirements on our servers would get out of control pretty quickly.
I am hoping(?) that you could use the SQL tags in a similar fashion to specify what subset of data you wanted. Will have to look into that more. On the other hand, if these tags are meant for simple apps, then maybe this type of functionality isn't appropriate since it might encourage you to use the tags in situations they shouldn't be used for.
James Carman
Ranch Hand

Joined: Feb 20, 2001
Posts: 580
The query tag does have startRow and maxRows attributes to support "pagination" of result sets. My point was that if I don't want pagination, I'm stuck having all of the results cached in memory. Yuck! As a matter of fact, some JDBC drivers (The MySQL MM driver for example) already cache the entire result set into memory, so with this query tag there would be two copies of the entire result set in memory! Ouch!
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1441
Or double ouch in that case! Thanks for the info, James.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Uses for JSTL SQL tags?
 
Similar Threads
JSTL SQL XML data source / driver?
JSP and Database tables
javax.el.PropertyNotFoundException: Property 'empname' not found on type java.lang.String
JSTL in struts 2
Populating one drop down based on the other