A new article "Introducing the JSP Standard Tag Library (JSTL)" has been posted on TheServerSide. For programmers and nonprogrammers alike, JSTL provides simple and reusable tools for common web-development tasks: loops, conditions, database access, XML manipulation, internationalization (i18n), text formatting, and more. In this article, we look at JSTL's basics -- its history, goals, and schedule.


Read this article here

I think graphic part of jsp is missing, instead of applets scalable vector graphics (svg) should be used with tags, I remember apache batik is similar project.

For Graphics I am using this
www.servletsuite.com/servlets/jpegtag.htm

The 'new expression language' looks exactly like the old ATG 'bean:', 'param:' syntax to me.

Yes, many features of JSTL were influenced by leaders in the respective fields. ATG was very influential in the development of the expression language, for example, while developers from Jakarta Taglibs had a lot to say about internationalization and text formatting.

By the way, my article (which was originally from Manning and is a month or two old) presents expression language (EL) syntax that is now slightly out of date. The expression language now looks more like ${pageScope.foo} than $page:foo. My upcoming book, "JSP Standard Tag Library: Learning JSTL," describes the EL syntax (and all other JSTL features) in detail.

There is more info on the JSTL and expression language at:
http://www.onjava.com/pub/a/pub/a/onjava/2002/05/08/jstl.html

Nice adverts, pity about the content...

So, was there something more you wanted? I'm happy to answer any questions you've got about JSTL. The article was just an introduction for novices, given that the technology is oriented primarily at nonprogramming "page authors."

I was looking for more depth also.
There are a shortage of good examples that
go beyond hello world.

If you don't use the special context defaults for the DataSource, how can one put information into the
driver and url parms from a source such as
SessionContext.getInitParameter("driver") or
ServletConfig.getInitParameter("url")
into sql.

<sql:driver var="dataSource" />

<sql:query var="trips" dataSource="${dataSource}" >
SELECT * from trips
</sql:query>

Is this the best language?
The syntax seems difficult at best.

You can either install a new DataSource using <sql:setDataSource>, with syntax like the following:

<sql:setDataSource dataSource="..."/>

Or you can install one in controller code (e.g., a back-end servlet) by using JSTL's configuration API, exposed and documented by the standard (and discussed in chapter 14 of my book). This gives you somewhat more programmatic control and convenience.

Remember, this article wasn't designed to discuss JSTL in detail; it was intended just to introduce the topic. On the mailing lists at Jakarta, in my book, and elsewhere, I and others have been discussing JSTL in detail. This was just an introductory article I posted on manning.com that TheServerSide asked if they could reprint.

Where is the "configuration API" documented?
I went to c:\jstl-20020504\jakarta-taglibs\doc\doc\standard-doc\Overview.html and couldn't find anything like that.

Also, could not find <sql:setDriver at
c:\jstl-20020504\jakarta-taglibs\doc\doc\standard-doc\DB_FunctionalDescription_1_EA3.html

Am I missing something?

Yes, the pages that you're looking at are out of date. The JSTL specification will soon be finalized; in the meantime, you can download the Proposed Final Draft, which is equivalent to the standard in all but a few minor details, at

http://java.sun.com/products/jsp/jstl/

The spec is the authoritative source for all JSTL information (including the back-end Java APIs associated with JSTL). My book (http://www.jstlbook.com) also describes the configuration APIs.

JSTL is great ! However, I&#8217;ve got an impression that, from architectural perspectives, Sun has always recommend to decouple presentation from the back-end, i.e. Web page from direct access to a database. What architectural rational do you see in JSTL database access feature rather than &#8220; people want it because they used to use it&#8221; ( since early days of Web development ) ? Is it a new wind from Sun to put such feature into the standard ?
Thanks,
Michael

Good question. While JSTL does more than simply provide access to databases, you're right that RDBMS access is one feature of JSTL. I can't speak for the Java Community Process as a whole, but I believe it's pretty safe to say that this does not represent a new architectural direction for enterprise Java. Instead, JSTL includes database support with the recognition that (a) not all applications are large; (b) not everyone adopts the MVC pattern; and (c) many users ask for the feature. Even in an enterprise application, not all data needs to be abstracted away from the presentation tier; for instance, imagine a situation where data is stored specifically for the presentation tier and does not represent "business objects" of any sort.

I think JSTL is borrowing a lot from
Velocity, although JSTL is still not
as good as Velocity. JSTL is a great
improvement over JSP.

Velocity syntax is still much more
readable. JSTL does not have macro.

An effort to integrate these two will
be very useful.

JSTL doesn't really borrow much from Velocity; it's based on similar principles, but nobody from Velocity was instrumental in the JSTL expert group. Are there specific Velocity features that you think JSTL could benefit from? JSTL supports a much simpler contract between the page author and programmer than Velocity provides; the user of JSTL needs to know less to maintain JSTL pages than a user of Velocity needs to maintain Velocity pages. (For instance, a JSTL user need not have any understanding of Java types or method invocation. This is intentional.)

It turns out that Velocity user need not
know Java types, either. Older JSPs
force user to do type conversion. Veolcity
uses introspection.

Good stuff in Velocity :
- Macro.
- More human readable syntax - even though
  JSTL has greatly improved over JSP.
- ...

It shall be straight-forward to translate
between Velocity and JSTL - this is going
to be a good open source project.

Overall, I think JSTL shall have a better
future than JSP.

One thing I don't like about Velocity, though, is that the types aren't really hidden; to call a method, you really need to know what type the object is -- or at least to know what methods are available, what types they accept, and so forth. While you might find tags less readable (a debatable view since the technology is presented to page authors who know HTML but not programming languages), they serve as a valuable point of abstraction.

But overall, I think I agree with much of what you say about the future of JSP.

Hi,

I am a ColdFusion/Java programmer. I have been using ColdFusion for the last 3.5 years. I have to say that JSTL is a complete rip off of the ColdFusion programming concept. This is not a 'new' concept, ColdFusion has offered a complete tag based language for years. Even the organisation of data into application,session,request, and page scope is identical to ColdFusion.

Everything seems too similar to ColdFusion to be a coincidence, JSTL should have been implemented years ago....

My 2 cents.

ColdFusion, along with many other technologies, were inspirations for JSTL; I believe the very introduction of JSP tags was proposed originally, at least in part, by the folks at Live Software, which later became Allaire and merged into Macromedia. In other words, none of this is covert; Macromedia voted "Yes" for the technology in the Java Community Process vote, and they were an important contributor to the technology, along with Sun, ATG, other companies, and a handful of individuals like myself. The idea of "ripping off" an idea doesn't apply in this environment; this is an open community.

The major goal is to improve JSP by making it easier to develop; JSTL's novelty lies primarily in its relationship to JSP and what it does for server-side Java in general.

If you look at the details (and beyond just the glossy introduction in my article), you'll find that JSP + JSTL offers a number of different features, and present existing features in different ways, than JSTL. All major environments (e.g., JSP, ASP, and ColdFusion) share the idea of session scopes, application scopes, and so forth; JSTL is not intended to be unique in this regard, and it is not presented as such. JSTL does offer some new features, however; for instance, it provides relatively novel, interesting ways to manipulate XML imperatively, and its expression language is targeted to a more novice audience than existing expression languages, thus simplifying the contract between the back-end developer and the page author (and thus increasing potential maintainability).

Hi Shawn Bayern,

Just to intro myself, uve replied me over mail during the JSTL beta1 for connecting JNDI datasource using a relative path and it was there in the next beta and in the final release too. Tx for that.

But, Ive few questions Shawn. We are Java Dev. only and we are developing web applications, with full of JSP and servlets only. We dont use EJB, cos of J2EE app. servers price and our clients are not ready to invest that much. So, JSTL will be very much usefull for us in our next projects. Here, my doubts are...

1. When can we expect a beta release of Java Server Faces/JSF

2. Will JSP and JSTL will be useful once JSF is released

3. Since JSF is a Swing like design env., lot of lools will come to design web app. using JSF like Swing. Also, again, JSF will be converted into servlets for rendering pages, or will there be some other mechanism like applets will be used to render them

4. If JSTL will still be used with JSF, y there is tags to access Web Services and EJB's from it

5. When JSP will provide an environment for client side validation like ASP.NET, where we dont have to use Java Script and all. Y im asking this is, as u said in ur article, there is no seperate developers for designing the forms, we JSP developers design the web forms and jsp coding, since this is full of DB oriented web application similar to c/s forms.

Hope u understand y im asking for the 1st beta release of JSF. If we start with JSTL in our next pro., if JSF will replace JSP and JSTL, then we can wait for JSF itself and continue with JSP itself.

Also, y can't we put the common jar's in common/lib in Tomcat to use JSTL. This will def. reduce the size of the war files, which we can use without the JSTL related jar files.

Yours,
Sanka.B
India
jinishans@yaoo.com

4. If JSTL will still be used with JSF, y there is NO tags to access Web Services and EJB's from it