Web Tier to Go With Java EE 5: Introducing the EL #{…} Syntax

Print-friendly Version

The first article in the "Web Tier to Go With Java EE 5" series, "Summary of New Features in JavaServer Pages (JSP) 2.1 Technology," introduced the new unified expression language. This fifth article of the series explains

• The new #{…} syntax that the unified expression language supports
• How #{…} expressions differ from ${…}expressions
• Why the expert groups for JavaServer Pages (JSP) and JavaServer Faces technologies settled on two syntaxes instead of a single one

The expression language (EL) introduced in JSP 2.0 significantly simplified access to application data in JSP files. For example, the following expression accesses the name of a customer.

  ${customer.name}

The dollar-sign character triggers the evaluation of an EL expression by the JSP software engine. In terms of the preceding example, the expression ${customer.name} is used to look up the customer JavaBeans component and call the getName method to retrieve the value of the name property. This value is then rendered into the page.

In the early versions of JSP technology, page authors had to use scriptlets (pieces of Java programming language code) to insert dynamic data into their pages. With the expression language—along with other ease-of-use features available in JSP technology—page authors can write JSP pages that are totally free of code.

During the development of JSP 2.0 technology, another web technology offering significant ease-of-use features appeared on the scene: JavaServer Faces technology. This technology's primary feature is its flexible and extensible UI component model, which includes

• A set of classes that define UI components
• A mechanism for handling events generated by the components
• A process for converting and validating component data

It also includes a set of component tags that are used to map directly to individual, stateful, server-side UI component objects.

A JavaServer Faces page implemented using JSP technology should look very familiar to a JSP page author, except for one thing: Its EL expressions make use of a different syntax, the pound syntax (also known as the sharp syntax, octothorpe syntax, and number-sign syntax): #{…}. Why introduce an additional syntax? The answer to this question lies in the differences between the request-processing models used in JSP technology and JavaServer Faces technology.

As shown in figure 1, the request processing performed on a JSP page is very simple. The JSP engine simply takes the mix of static and dynamic data that it encounters in a page and writes the data to the HTTP response.

Figure 1: JSP request processing

In JSP 2.0, an EL expression is always evaluated as soon as it is encountered by the JSP engine. These expressions are therefore referred to as immediate expressions. They yield a read-only value, which is also known as an rvalue. In programming language terminology, an rvalue represents the right-hand side of an assignment expression.

An immediate expression is all that is needed in the context of JSP pages, because the request-processing model features a single phase of execution called the render phase, during which static and dynamic data is immediately written to the response.

The story is quite different for a JavaServer Faces page. It is structured as a tree of UI components that is subjected to a much more complex request-processing life cycle, as shown in Figure 2.

Figure 2: JavaServer Faces life cycle

When a page is first displayed, components simply render themselves. Through their renderers, they write data to the HTTP response. This is exactly the same behavior as a normal JSP tag. However, the power of JavaServer Faces technology lies in its ability to abstract the handling of input components when a form is submitted back to the server for processing. This is where the JavaServer Faces request processing life cycle really shines.

For example, consider the following JavaServer Faces component tag:

    <h:form>
      <h:inputText
          value="#{handler.email}"
           validator="#{handler.validateEmail}"/>
    </h:form>

When the form is submitted, the apply request values phase of the JavaServer Faces life cycle evaluates the EL expression #{handler.email} as a reference to a data structure whose value is set with the input parameter that the form associates with it. The result of the expression therefore represents an lvalue, which is a reference to data. In programming language terminology, an lvalue represents the left-hand side of an assignment exrpession.

If the user enters john@mycompany.com into the text field of this form, then the property email of the handler object is set to that value. Anyone who has had to do this manually with JSP and servlets will quickly realize what an improvement this is. When that same expression is evaluated during the rendering phase, it yields the specific value (an rvalue) associated with the object, just as would be the case with the expression ${handler.email} in a JSP page.

A JavaServer Faces component tag also has a set of attributes for referencing methods that can perform certain functions on that component. In the preceding example, the validator attribute uses an EL expression to refer to the validateEmail() method of the handler object. This method is invoked at the appropriate phase to validate the component's input.

As the previous section demonstrates, EL expressions used in JavaServer Faces tags are clearly quite different from EL expressions used in JSP pages. With the ${…} syntax, the expression is evaluated immediately when encountered by the JSP engine. Because JavaServer Faces expressions need to be evaluated at different times during the request-processing life cyle, they are called deferred expressions and use the #{…} syntax. When a deferred expression is encountered by the JSP engine, it is not evaluated. Rather, it is passed to the tag handler as an expression, which can then be evaluated whenever needed by the logic implemented by the tag handler.

You could argue, however, that a single syntax could have done the job. Indeed, a deferred expression can only be used in the context of a tag handler. Furthermore, it is a requirement for a tag handler to declare whether an attribute accepts immediate or deferred expressions because the JSP engine must know how to deal with the expression. Given that it is the tag developer who dictates whether immediate or deferred expressions are accepted by a specific tag attribute, it is definitely legitimate to question why two different syntaxes have been defined while a single one would have sufficed.

The expert groups for the JSP and JavaServer Faces technologies have debated this question at great length. While they agreed that it seems simpler to support a single syntax for EL expressions (whether they are immediate or deferred), the expert groups also had to consider the fact that both syntaxes were already well established in their respective communities. Deprecating a syntax in favor of the other one would have been painful for the affected community, so the expert groups finally decided to keep the two syntaxes, each with its own semantics. This is an acceptable compromise, given that both history and backwards compatibility had to be considered.

Finally, you might also wonder whether attributes in JavaServer Faces components that are strictly used with read-only values really have a need for deferred expressions. For example, the following tag represents a component that simply writes the content of the value attribute to the HTTP response.

<h:outputText value="#{customer.name}"/>

In this case, why not simply use ${customer.name} as the value? There are two reasons. First of all, while the use of an immediate expression could work in most cases, it is important to note that the component value would be evaluated immediately when the component tree is built, and therefore fixed. If the value of customer is ever changed during one of the phases in the postback, an erroneous value would be displayed. Secondly, and more importantly, JavaServer Faces components declare all their attributes as deferred expressions for consistency. A page author never has to guess whether the ${…} or #{…} syntax should be used with a JavaServer Faces component; the #{…} syntax must always be used.

As this article explained, the new unified expression language's support for the dollar-sign and pound syntaxes is important for aligning JSP and JavaServer Faces technologies, satisfying the needs for both immediate and deferred expressions, and for preserving backwards compatibility. See the article Unified Expression Language to learn more about the unified expression language. Meanwhile, watch for the next article in this series on the improvements made to the tree-creation and content-interweaving mechanisms supported by JavaServer Faces technology.

Other articles in the "Web Tier to Go With Java EE 5" series:

• Part 1: Summary of New Features in JSP 2.1 Technology
• Part 2: Summary of New Features in Java Standard Tag Library (JSTL) 1.2
• Part 3: Summary of New Features in JavaServer Faces 1.2 Technology
• Part 4: A Look at Resource Injection

JavaServer Pages Technology FAQ
JSR 245: JavaServer Pages 2.1
JSP project on java.net: jsp-spec-public
JavaServer Faces technology
JSR 252: JavaServer Faces 1.2
Java EE 5 Technologies
Unified Expression Language (EL)
New Features Added to Servlet 2.5
Java Forums -- JavaServer Pages (JSP) and JSTL