Overview

This document provides a high level overview of the JSP™ Standard Tag Library (JSTL) as it stands for Beta 2. If you have a strong opinion on the topic — positive (you really like it), or constructive (we messed up some parts and you have some constructive comments for improvements) — we'll be happy to hear from you at jsr-52-comments@jcp.org. All comments will be read but we cannot guaranteee personal replies to all of them.

Make sure you read this document first, then check out the jstl-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. You should use JSTL only in prototype webapps because this is Early Access and things may/will change as we gather feedback and make adjustments. Thanks for your help making JSTL an awesome standard tag library...

Design Philosophy

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. EA1 defines the foundation elements to make this possible.

Multiple TLDs

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

Expression Language Support

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

It is a hard task for the Expert Group to decide on a specific EL without first getting the general feeling from the community. This is why JSTL currently does not define a specific EL, but provides mechanisms for experimentation with a variety of ELs. Tell us what you feel is important for that EL, and feel free to implement one that others can experiment with. The goal is to select a single EL once the JSTL spec is ready for Community Review.

Early Access contains several candidate Expression Languages. One of them is an implementation subset of ECMAScript (JavaScript) and is the one used by default. Please check EcmaScript as an Expression Language for JSTL.

Tag Collaboration

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

The fact that JSTL tags do not expose scripting variables would make it hard to collaborate with other tags whose data must be passed as rtexprvalues. To that effect, tag <declare> allows to declare a scripting variable to be associated with the JSP scoped attribute of the same name.

Tag Overloading

In JSTL, we try as much as possible to avoid too much "overloading" of a tag; i.e. tags with lots of attributes that can do just about anything. Rather, we privilege a larger number of tags with well focused behavior.