Copy from 

An Introduction to JSTL by Sue Spielman

Have you heard about the JSTL but aren't quite sure of how to make the best use of it? The JSTL: Practical Guide for JSP Programmers covers everything you need to know to get started and become productive using the JSP Standard Tag Library. The Practical Guide series continues to be packed with information for real developers and is written in a straightforward and easy-to-use manner. The book has just been released and comes with free download of all code examples used throughout. Each standard action is covered with a detailed explanation and includes a code sample so you can start using the JSTL immediately.
The following sections are excerpted from various chapters within the JSTL: Practical Guide for Java Programmers. The selected sections should give you a taste of what you can learn from the book. Sue Spielman will be in the JSP forum the week of Sept 30 answering questions and will also be giving away complimentary copies of the JSTL: Practical Guide for JSP Programmers.


JSTL is the JSP Standard Tag Library. The JSTL came about under JSR-52 of the Java Community Process (JCP). The specification can be found at . JSR-52 covers the creation of a standard tag library for JavaServer Pages and allows this library to be available to all compliant JSP containers. These tag libraries provide a wide range of custom action functionality that most JSP authors have found themselves in need of in the past. Having a defined specification for how the functionality is implemented means that a page author can learn these custom actions once and then use and reuse them on all future products on all application containers that support the specification. Using the JSTL will not only make your JSPs more readable and maintainable, but will allow you to concentrate on good design and implementation practices in your pages. We can finally take the 祖ustom' out of custom action and replace it with 壮tandard' .No more creating your own iteration action for the tenth time. Additionally, your favorite Integrated Development Environment (IDE) that supports JSP authoring will now support these standard actions and can assist the JSP page author in rapid development.

Functional Overview

The JSTL encapsulates common functionality that a typical JSP author would encounter. This set of common functionality has come about through the input of the various members of the expert group. Since this expert group has a good cross section of JSP authors and users, the actions provided in the JSTL should suit a wide audience. The JSTL is a set of custom actions that is based on the JSP 1.2 and Servlet 2.3 specifications. While the JSTL is commonly referred to as a single tag library, it is actually composed of four separate tag libraries:
  • Core
  • XML manipulation
  • SQL
  • Internationalization and formatting
These libraries are defined by the Tag Library Descriptor files. Using separate TLDs to expose the tags, the functionality for each set of actions is apparent and makes more
sense. Using separate TLDs also allows each library to have its own namespace. To sum up for now, the layout of the JSTL is straightforward. The overriding theme throughout the JSTL is simplifying the life of the page author. The page author is the person who builds the JSP pages. There has always been a need (although not a requirement) that the page authors have some understanding of a programming language (usually Java)in order to create complex pages. This dilemma is what has hampered the true role separation between the JSP page author and the Java programmer. Using the tags provided in the JSTL, we are closer to reaching that clean division of labor. The functional areas in the JSTL help page authors identify what type of functionality they need and where they can find it.

Using the Expression Language

Before we dive into the various functional areas in the JSTL, we should start with the expression language. As touched on briefly in the first chapter, this is one of the most important features of the JSTL and is a prominent feature of the JSP 2.0 specification. The expression language (EL) allows for a much simpler syntax for doing application data manipulation for the page author. Currently the EL in the JSTL can only be used with tag attribute values, primarily in actions that reside in the Core tag library. It is possible to use the EL within template text if you are working with the JSP 2.0 specification. Expressions in template text are not supported if you are using JSTL 1.0 with JSP 1.2. What it means to use EL in attributes can be shown in the following example:
<c:if test="${book.orderQuantity >book.inStock}">
The book <c:out value="${book.title}"/>is currently out of stock.
Using the <c:if>conditional tag (which we'll talk about in detail shortly),we can use the EL in the test attribute to determine if we can order a book that is currently in stock. If the book is not in stock, we can access the book Object by using the EL and assigning that to the value attribute. Anyone who has worked with JSPs before can certainly appreciate the ease-of-use and coding simplification possible with the EL. If you are working with JSP 2.0,this sample could also be written using the expression in the template text like:
<c:if test="${book.orderQuantity >book.inStock}">
The book ${book.title}is currently out of stock.
Keep in mind that when using an identifier (like book ,for example) with the EL, it is the same thing as if you had done PageContext.findAttribute(identifier ).The identifier itself can reside in any of the known JSP scopes. This includes page ,request ,session ,or application scope. If the identifier isn't found in any scope, then a null value is returned.

Implicit Objects Available in the EL

There are quite a few implicit objects exposed through the EL. These objects allow for access to any variables that are held in the particular JSP scopes. Objects include pageScope, requestScope, sessionScope, and applicationScope. All of these xScope objects are Maps that map the respective scope attribute names to their values. Using the implicit objects param and paramValues, it is also possible to access HTTP request parameters. This holds true for request header information as well as for using the implicit objects header and headerValues.
The param and header objects are Maps that map the parameter or header name to a String .This is similar to doing a ServletRequest.getParameter(String name) or ServletRequest.getHeader(String name).The paramValues and headerValues are Maps that map parameter and header names to a String[] of all values for that parameter or header. Again, this is as if you had madeServletRequest.getParameterValues(String name) or ServletRequest.getHeaders(String) calls.
The initParam gives access to context initialization parameters, while cookie exposes cookies received in the request. The implicit object pageContext gives access to all properties associated with thePageContext of a JSP page such as the HttpServletRequest ServletContext ,and HttpSession objects and their properties.
Let's look at a couple of samples to drive the usage of the objects home:
  • ${pageContext.request.servletPath} will return the Servlet path obtained from the HttpServletRequest.
  • ${sessionScope.loginId} will return the session-scoped attribute named "LoginId" or null if the attribute is not found.
  • ${param.bookId} will return the String value of the bookId parameter, or null if it is not found.
  • ${paramValues.bookId} will return the String []containing all values of the bookId parameter, or null if it is not found. Using paramValues is particularly useful if you have a form with check boxes or for some other reason a parameter might have multiple values like a multiselect box.
The EL operations are necessary to handle data manipulations. All of the standard and common operators are available. Functionality is included in the EL for relational, arithmetic, and logical operators.

Automatic Type Conversion

The automatic type conversion is a very convenient feature of the EL in that a full set of coercion between various object and primitive types is supported. Coercion means that the page author isn't responsible for converting parameters into the appropriate objects or primitives. The JSTL defines appropriate conversions and default values. For example, a String parameter from a request will be coerced to the appropriate object or primitive.
If we are dealing with , which is an item or object, the coercion rules supplied by the JSTL will be applied for each given type. These coercions are done under the covers for you by the implementation, but it is always a good idea to understand how, and in what order, the rules are being applied. For this reason, I'm including the coercion rules from the JSTL 1.0 specification in JSTL Reference section so that you can review them if you want.
Let's look at Example 3.1.If we have a variable called myInteger and want to use the value in an expression as a number, we simply declare a variable with the value using <c:set>.If a parameter that represents the month is passed in the request as a String , the value of the month variable will be correct because the String will be coerced to the correct type when used. If the value of the parameter does not parse correctly to a number (say, the value is September instead of 9) at that point an exception will be thrown. Having automatic type conversions can save unnecessary exceptions from happening.

Some examples: