1.4 JSTL Design Principles

This chapter concludes with a discussion of some fundamental JSTL design principles. To make the best use of JSTL, you should understand those design principles; they apply to many, if not all, of the JSTL actions. The design principles discussed in this section are:

• Naming conventions

• Scoped variables

• Dynamic attributes

• Error handling

• Configuration settings

Naming Conventions for JSTL Actions

JSTL actions and their attributes use the Java naming convention ”they start with lower case, and subsequent words begin with upper case; for example:

 <c:  out value  ='${param.amount}'/>  <c:  forEach  var='item' items='${names}'  varStatus  ='status'> 

Some attribute names, such as var and scope , are used by many JSTL actions and always have the same semantic value. The next section discusses those attributes.

Scoped Variables vs. Scripting Variables

Actions are a conduit between JSP pages and Java code. Through that conduit flows information from JSP page to Java code, and vice versa. For example, consider this code:

 <c:forEach var='  item  ' begin='1' end='10'>     value = <c:out value='${  item  }'/><br> </c:forEach> 

In the preceding code fragment, the JSP page uses the <c:forEach> action to send information ”such as the value of the var attribute, which represents the current item in the iteration ”to the tag's handler, which is written in the Java programming language. The tag handler exports an object named item and makes it available, as a scoped variable, to the body of the <c:forEach> action.

Many JSTL actions export scoped variables that you can easily access through the expression language, as is the case for the preceding code fragment. Realize that this is in contrast to most JSP custom actions, which typically make objects available to JSP pages with scripting variables, which are accessed with JSP expressions and scriptlets.

The var and scope Attributes

If a JSTL action makes a scoped variable available to one or more JSP pages, it will have an attribute named var that lets you specify the name of that scoped variable. Actions that make that scoped variable available outside their body also have a scope attribute that lets you specify the scoped variable's scope. For example, the following code fragment uses <fmt:message> to store a localized message in a scoped variable:

 <fmt:message key='index.greeting'  var  ='msg'  scope  ='request'/> 

If you don't specify the var and scope attributes, the <fmt:message> action will send the localized message corresponding to the specified key to the current JspWriter . If you specify the var attribute, <fmt:message> stores the localized message in a scoped variable whose name corresponds to the var attribute's value; for example, in the preceding code fragment the <fmt:message> action stores the value corresponding to the index.greeting key in a scoped variable named msg that resides in request scope.

If a JSTL action has var and scope attributes, you can leave the scope unspecified, and it will default to page scope; for example, the preceding code fragment could be modified like this:

 <fmt:message key='index.greeting'  var  ='msg'/> 

The <fmt:message> action listed above also stores a localized message in a scoped variable named msg , but because the scope attribute was not specified, that variable resides in page scope.

Some JSTL actions can export more than one scoped variable; in those cases, the primary scoped variable is named with the var attribute and its scope is specified with the scope attribute, whereas the names of other scoped variables are specified with an attribute named var XXX and their corresponding scope attribute, if available, is named scope XXX , where XXX represents the semantics of the scoped variable. For example, the <x:parse> action has var and scope attributes for the parsed XML document, but you can specify the varDOM and scopeDOM attributes instead if you want to force <x:parse> to use the Document Object Model (DOM).

Scoped Variable Visibility

Scoped variables created by JSTL actions are visible either within the body of the action or after the action's end tag. The scope of the former is referred to as nested, and the scope of the latter is referred to as at-end. The life cycle of an at-end scoped variable depends on its scope.

Static vs. Dynamic Action Attributes

Values specified for JSTL action attributes can be static or dynamic. Dynamic attributes can be specified with EL expressions for actions in the EL library or with JSP expressions for actions in the RT library. Static attributes are specified with strings.

Nearly all JSTL action attributes are dynamic, except for the var and scope attributes (and var XXX and scope XXX attributes) discussed in "The var and scope Attributes" on page 35 and the select attribute for the JSTL XML actions. Requiring static values for those attributes is beneficial to tools, with few drawbacks for JSP developers.

Error Handling

JSTL does all it can to avoid throwing exceptions, so in many cases if you specify an action's value as null or an empty string, that value will be coerced ”see "Type Coercion" on page 62 ”to a harmless constant; for example, if you look at "JSTL Type Coercion" on page 62, you can see that null values are coerced to when an attribute expects a number.

Besides the expression language's built-in type coercion, the library actions themselves do their best to interpret nonsensical values as harmless constants; for example, the <c:forEach> action will do nothing if you specify a null value for its items attribute. That default behavior, for example, makes it practical to iterate over form data that contains unchecked checkboxes.

Table 1.8 shows how JSTL handles errors for certain types of attributes.

Table 1.8. JSTL Attribute Error Handling

Attribute	If value is invalid:
var	Translation-time validation error
scope	Translation-time validation error
Dynamic, with a fixed-set of possible values	If the value is null , it's coerced to a default value; otherwise , other invalid values will cause an exception to be thrown.
Dynamic, without a fixed-set of possible values	If the value is null , the result is action dependent; other invalid values will cause an exception to be thrown.

Exceptions caused by an action's body content, the action itself, the expression language, or XPath are always propagated. You can use the <c:catch> action to catch those exceptions; see "The <c:catch> Action" on page 126 for more information about the <c:catch> action.

Configuration Settings

Some of the more specialized JSTL actions, such as the SQL and formatting actions, use JSTL configuration settings to specify a value that's shared among a set of JSTL actions. A configuration setting is a combination of a context initialization parameter and a configuration variable that can be used to override that initialization parameter for a particular JSP scope. See Chapter 6, "Configuration Settings," for more information about configuration settings.