This document provides a high level overview of the JSP™ Standard Tag Library (JSTL).
Make sure you read this document first, then check out the standard-examples web application in the release (once you have installed it on your web container following the instructions in the Getting Started document). This will help you get a good feel for what JSTL is all about. Then browse the other docs to get all the details, and finally give JSTL a ride in your own prototype web application. Thanks for your help making JSTL an awesome standard tag library.
JSP tag libraries help provide a clean separation between the business logic and the presentation layer of web applications. By keeping the programming logic out of JSP pages, web designers are now empowered to develop sophisticated JSP pages without having to resort to the scripting language associated with their JSP pages (usually the Java programming language).
The base design philosophy in JSTL is therefore to provide page authors with a script free environment.
A Tag Library is a collection of actions that encapsulate functionality to be used from within a JSP page. JSTL includes a wide variety of actions that naturally fit into discrete functional areas. This is why JSTL, altough a single standard tag library, is exposed via multiple TLDs to clearly show the functional areas it covers, as well as to give each one of them their own namespace. The table below lists these functional areas along with their URI. The table also shows the prefixes used in our documentation and examples (although web applications can use any prefix they want).
| Funtional Area | URI | Prefix | Example |
|---|---|---|---|
| Core | http://java.sun.com/jstl/core |
c
|
<c:tagname ...> |
| XML processing | http://java.sun.com/jstl/xml |
x
|
<x:tagname ...> |
| I18N capable formatting | http://java.sun.com/jstl/fmt |
fmt
|
<fmt:tagname ...> |
| Database access (SQL) | http://java.sun.com/jstl/sql |
sql
|
<sql:tagname ...> |
A key contribution of JSTL is the integration of an Expression Language (EL). An EL leverages the fact that JSP scoped attributes are the privileged way to communicate information from the business logic to the JSP pages. It makes it possible to easily access application data and manipulate it in simple ways without having to use scriptlets or request-time expression values.
For example, this conditional tag tests whether the country of a customer is the USA.
<c:if test="${customer.address.country == 'USA'}">
...
</c:if>
There were quite a few issues involved with the support of an Expression Language within JSTL given the constraint that it had to work without requiring any change to the JSP spec. In order to be able to support both the scripting (rtexprvalues) and the EL (elexprvalues) worlds, we had to come up with the concept of twin tag libraries: one that supports the expression language, and one that supports request time expression values. Our assumption is that people will mostly use the EL-based tag libraries, while it is still possible for hard core scripting page authors to use JSTL with rtexprvalues (provides benefits for type safety and performance) via the request-time based tag libraries (their URI simply has the "_rt" suffix appended).
After a lot of productive deliberation, the JSR-052 expert group determined the syntax for a single expression language in JSTL.
Tags usually collaborate with their environment in implicit and/or explicit ways. Implicit collaboration is done via a well defined interface that allows nested tags to work seamleasly with the ancestor tag exposing that interface. The JSTL iterator tags support this mode of collaboration. Explicit collaboration happens when a tag explicitely exposes information to its environment. Traditionally, this has been done by exposing a scripting variable (with a JSP scoped attribute providing the actual object). Because JSTL supports an expression language, the need for scripting variables is significantly reduced. This is why all the JSTL tags expose information only as JSP scoped attributes (no scripting variable exposed). A bold move, we agree, but we feel this is the proper design decision to support script-free JSP pages.
The convention is to use the name "var" for any tag attribute that exports information about the tag. For example, an iterator tag exposes the current item of the collection it is iterating over in the following way:
<c:forEach var="customer" items="${customers}">
...
</c:forEach>
It is important to note that a name different than "id" was selected to stress the fact that a variable is exposed (actually a JSP scoped attribute), but not a scripting variable (which is normally the case when using an attribute named "id").
The convention also establishes the attribute "scope" to set the scope (page, request, session, application) of the JSP scoped attribute.
In situations where a tag exposes more than one piece of information, the name
"var" is used for the primary piece of information being exported,
and an appropriate name is selected for any other secondary piece of information
exposed (e.g. an iteration current status information is exported by the foreach
tag via attribute status.)
One of the design principles of JSTL is to avoid too much "overloading" of a tag, that is, to avoid tags with lots of attributes that can do just about anything. Instead, JSTL gives preference to a (slightly) larger number of tags with well focused behavior.