The expr in ${expr} can contain literals, operators, and references to objects and methods. Table 4-5 shows some examples and their results.
Table 4-5. EL Expressions
EL Expression Result
${1 <= (1/2)} false
${5.0 > 3} true
${100.0 == 100} true
${'a' < 'b'} true
EL Expression Result
${'fluke' gt 'flute'} false
${1.5E2 + 1.5} 151.5
${1 div 2} 0.5
${12 mod 5} 2
${empty param.a} true if the request parameter a is null or an empty string
${sessionScope.cart.nItems} The value of the nItems property of the session-scoped attribute named cart
${aBean.aProp} The value of the aProp property of the aBean bean
${aMap[entryName]} The value of the entry named entryName in the map named aMap
The operators behave in general like in Java, but with one important difference: the equality operator (==) applied to string variables compares their contents, not whether the variables refer to the same instance of a string. That is, it behaves like Java’s String.equals() method.
In addition to EL operators identical to Java operators, you also have most of their literal
equivalents: not for !, div for /, mod for %, lt for <, gt for >, le for <=, ge for >=, eq for ==, ne for !=, and for
&&, and or for ||. You also have the unary operator empty, to be used as shown in one of the examples in Table 4-2.
The EL operators '.' (i.e., the dot) and [] (i.e., indexing) are more powerful and forgiving than the corresponding Java operators.
When applied to a bean, as in ${myBean.prop}, the dot operator is interpreted as an indication that the value of the property should be returned, as if you’d written myBean.getProp() in a scripting element.
As a result, for example, the line of code
${pageContext.servletContext.servletContextName}
is equivalent to this:
<%=pageContext.getServletContext().getServletContextName()%>
Furthermore, ${first.second.third}, equivalent to <%=first.getSecond().getThird()%>, returns null when first.second evaluates to null, although in the expression, we try to dereference it with .third. The JSP scripting equivalent would throw a NullPointerException. For this to work, all classes must implement the getter methods of properly formed Java beans.
Array indexing allows you to try to access an element that doesn’t exist, in which case it simply evaluates to null. For example, if you have an array of ten elements, the EL expression ${myArray[999]}
returns null instead of throwing an ArrayIndexOutOfBoundsException, as Java would have done. It is not as bad as in the plain old “C” language, in which an index out of bounds would have returned the value it found in memory. With EL, you can check for null. And in general you should do so, because you cannot rely on an exception being thrown, as it would be in Java.
You can use both the dot and indexing operator to access maps. For example, the following two EL expressions both return the value associated with the key named myKey:
${myMap.myKey}
${myMap["myKey"]}
There is a tiny difference, though: you cannot use the dot operator if the name of the key contains a character that confuses EL. For example, ${header["user-agent"]} is OK, but ${header.user-agent}
doesn’t work, because the dash between user and agent in the second expression is interpreted as a minus sign. Unless you have a variable named agent, both header.user and agent evaluate to null and, according to the EL specification document, ${null - null} evaluates to zero. Therefore, the second expression would return a zero. You would encounter a different, but potentially more serious, problem if you had a map key containing a dot. For example, you could use ${param["my.par"]} without
problems, but ${param.my.par} would probably result in a null or, almost certainly, in something other than what you are looking for. This would be bad in any case, because null is a possible valid outcome. I suggest you use the bracketed form in all occasions and simply forget this issue.
Similar to JSP, EL contains implicit objects, which you find listed in Table 4-6.
Table 4-6. EL’s Implicit Objects
Object Description
pageContext The context of the JSP page. In particular, pageContext.servletContext gives you a reference to the same object referenced in JSP by the implicit variable
application. Similarly, pageContext.session is equivalent to JSP’s session, pageContext.request to JSP’s request, and pageContext.response to JSP’s response.
param Maps a request parameter name to its first value.
paramValues Maps a request parameter name to an array of its values.
header Maps a request header name to its first value.
headerValues Maps a request header name to an array of its values.
cookie Maps a cookie name to a single cookie.
initParam Maps the name of a context initialization parameter to its value.
pageScope Maps page-scoped variable names to their values.
requestScope Maps request-scoped variable names to their values.
sessionScope Maps session-scoped variable names to their values.
${aBean.aProp} The value of the aProp property of the aBean bean applicationScope Maps application-scoped variable names to their values.
Caution You cannot use JSP scripting variables within EL expressions.
You’ve probably noticed that EL doesn’t include any way of declaring variables. Within EL expressions, you can use variables set with the c:set JSTL core action (which I will describe in the next section) or scoped attributes. For example, all of the following definitions let you use the EL expression
${xyz}:
<c:set var="xyz" value="33"/>
<% session.setAttribute("xyz", "44"); %>
<% pageContext.setAttribute("xyz", "22"); %>
However, you have to pay attention to scope precedence. The variable set with c:set and the attribute in pageContext are the same variable. That is, c:set defines an attribute in the page context. The attribute in sessionContext is a different variable, and you cannot access it with ${xyz} because it is
“hidden” behind the attribute with the same name in the page context. To access a session attribute, you have to prefix its name with sessionScope, as in ${sessionScope.xyz}. If you don’t specify a scope, EL looks first in the page, then in the request, then in the session, and finally in the application scope.
Caution You cannot nest EL expressions. Expressions such as ${expr1[${expr2}]}
are illegal.
You can make composite expressions consisting of several EL expressions and additional text, as in the following example:
<c:set var="varName" value="Welcome ${firstName} ${lastName}!"/>
However, you cannot mix the ${} and #{} forms.