FAQ
History
PreviousHomeNext Search
Feedback
Divider

Expression Language Support

A primary feature of JSTL is its support for an expression language (EL). An expression language, in concert with JSTL tags, makes it possible to easily access application data and manipulate it in simple ways without having to use scriptlets or request-time expressions. Currently, a page author has to use an expression <%= aName %> to access the value of a system or user-defined JavaBeans component. For example:

<x:aTag att="<%= pageContext.getAttribute("aName") %>">  

Referring to nested bean properties is even more complex:

<%= aName.getFoo().getBar() %> 

This makes page authoring more complicated than it need be.

An expression language allows a page author to access an object using a simplified syntax such as

<x:atag att="${aName}">  

for a simple variable or

<x:aTag att="${aName.foo.bar}">  

for a nested property.

The JSTL expression language promotes JSP scoped attributes as the standard way to communicate information from business logic to JSP pages. For example, the test attribute of the this conditional tag is supplied with an expression that compares the number of items in the session-scoped attribute named cart with 0:

<c:if test="${sessionScope.cart.numberOfItems > 0}"> 
  ...
</c:if> 

The next version of the JSP specification will standardize on an expression language for all custom tag libraries. This release of JSTL includes a snapshot of that expression language.

Twin Libraries

The JSTL tag libraries come in two versions which differ only in the way they support the use of runtime expressions for attribute values.

In the JSTL-RT tag library, expressions are specified in the page's scripting language. This is exactly how things currently work in current tag libraries.

In the JSTL-EL tag library, expressions are specified in the JSTL expression language. An expression is a String literal in the syntax of the EL.

When using the EL tag library you cannot pass a scripting language expression for the value of an attribute. This rule makes it possible to validate the syntax of an expression at translation time.

JSTL Expression Language

The JSTL expression language is responsible for handling both expressions and literals. Expressions are enclosed by the ${ } characters. For example:

<c:if test="${bean1.a < 3}" /> 

Any value that does not begin with ${ is treated as a literal that is parsed to the expected type using the PropertyEditor for the expected type:

<c:if test="true" /> 

Literal values that contain the ${ characters must be escaped as follows:

<mytags:example attr1="an expression is ${'${'}true}" /> 

Attributes

Attributes are accessed by name, with an optional scope. Properties of attributes are accessed using the . operator, and may be nested arbitrarily.

The EL unifies the treatment of the . and [ ] operators. Thus, expr-a.expr-b is equivalent to expr-a[expr-b]. To evaluate expr-a[expr-b], evaluate expr-a into value-a and evaluate expr-b into value-b.

The EL evaluates an identifier by looking up its value as an attribute, according to the behavior of PageContext.findAttribute(String). For example, ${product} will look for the attribute named product, searching the page, request, session, and application scopes and will return its value. If the attribute is not found, null is returned. Note that an identifier that matches one of the implicit objects described in the next section will return that implicit object instead of an attribute value.

Implicit Objects

The JSTL expression language defines a set of implicit objects:

When an expression references one of these objects by name, the appropriate object is returned instead of the corresponding attribute. For example: ${pageContext} returns the PageContext object, even if there is an existing pageContext attribute containing some other value. Table 6-2 shows some examples of using these implicit objects.

Table 6-2 Example JSTL Expressions
Expression
Result
${pageContext.request.contextPath}
The context path (obtained from HttpServletRequest)
${sessionScope.cart.numberOfItems}
The numberOfItems property of the session-scoped attribute named cart
${param["mycom.productId"]}
The String value of the mycom.productId parameter

Literals

Operators

The EL provides the following operators:

Consult the JSTL 1.0 Specification for the precedence and effects of these operators.

Tag Collaboration

Tags usually collaborate with their environment in implicit and explicit ways. Implicit collaboration is done via a well defined interface that allows nested tags to work seamlessly with the ancestor tag exposing that interface. The JSTL iterator tags support this mode of collaboration.

Explicit collaboration happens when a tag 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 has an expression language, there is less need for scripting variables. So the JSTL tags (both the EL and RT versions) expose information only as JSP scoped attributes; no scripting variables are used. The convention JSTL follows is to use the name var for any tag attribute that exports information about the tag. For example, the forEach tag exposes the current item of the shopping cart it is iterating over in the following way:

<c:forEach var="item" items="${sessionScope.cart.items}">
  ...
</c:forEach> 

The name var was selected to highlight the fact that the scoped variable exposed is not a scripting variable (which is normally the case for attributes named id).

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. For example, iteration status information is exported by the forEach tag via the attribute status.

Divider
FAQ
History
PreviousHomeNext Search
Feedback
Divider

All of the material in The J2EE Tutorial for the Sun ONE Platform is copyright-protected and may not be published in other works without express written permission from Sun Microsystems.