The Artima Developer Community
This article is sponsored by the Java Community Process.

Leading-Edge Java
JSF and JSP: What's New in Java EE 5
A Conversation with Ed Burns and Jan Luehe
by Frank Sommers
May 17, 2006

<<  Page 2 of 3  >>

Advertisement

Unified Expression Language

Frank Sommers: You mentioned that the unified expression language now lives in its own specification document. What was the reason for that separation?

Ed Burns: JSF 1.1 delivered many innovations for Web developers, and we wanted to expose some of those outside of JSF, mainly so that JSP can take advantage of them. The result is that the expression language is now independent of its hosting technology. In time, we might expose this expression language even outside of Java EE, and at some point it may even occupy its own JSR.

For example, one of the things we are considering is for this expression language to provide data binding in Java SE applications. It would probably be a sub-language for data binding, similar to how the expression language is used to obtain values from a JSF component. In [Java] SE, it might be a Swing expression language.

Frank Sommers: What differentiates an expression language from a scripting language?

Ed Burns: An expression language, or EL, is not a full-fledged programming language—you can't write programs in an expression language. Instead, an expression language is used mainly as a short-hand for accessing values. It makes it easy for page authors to access variables within different scopes, for instance, and to access properties of values. In addition, expression languages provide the notion of having some model data, and can help in navigating that model data.

An expression language often comes with some predefined values with a scope, such as a page context. The expressions are resolved within that scope. And you can specify what that context is. In the unified JSF/JSP expression language, whenever you evaluate an expression, you provide the context for that evaluation. In other words, you specify the context in which a variable can be defined. In the JSP context, for instance, the variable scopes are page, session, or application.

The application developer provides an EL context factory. Of course, we provide some base classes for those context factories. But the interesting part is that the whole notion of these contexts are general, and we didn't include any Web concepts in the EL core. All those [Web- specific concepts] are brought into the EL by the application. The independence of the unified EL from Web technologies is reflected in that we promoted the EL-related classes into their own package, javax.el.

The context you specify is then taken into account as a model object name is evaluated into an object reference, and as object properties are resolved. This is done by one or more EL resolvers, defined by an ELResolver implementation. A resolver takes a part of an expression, a name-to-value reference, and resolves that to an object reference. There can be a chain of resolvers. Each element of the chain might be able to resolve a part of the expression within a context the resolver knows about.

You can decide what kind of resolvers to add into this resolver chain. In JSF, for instance, you have a managed bean resolver that knows how to resolve references in the context of managed beans. Or you have a JavaBean EL resolver: Given a POJO, it looks for naming conventions to resolve a value. For instance, if you say, user.address.street in the EL, the bean resolver would be used to resolve that expression to an object value given the bean naming patterns.

Within the context of the resolvers, expressions act as a means to get a value, and also as a means to set a value. For example, when rendering an input field, the initial render of the field may or may not have a default value. If it does, the default value will be obtained by performing a "get" operation. However, when the value of the field is filled in by the user and submitted to the server, the expression receives that value by performing a "set" operation on the server.

This is an important point, because it provides for plugability in the architecture. If a value cannot be resolved within the context of one resolver, resolution attempts will [bubble up] the chain of resolvers. So to support, say, the Spring Framework, you would plug in resolvers specific to Spring, and then the system can manipulate Spring beans.

The EL itself defines no [technology-specific] resolvers. The core EL package defined in javax.el provides only basic resolvers, such as those capable of operating on maps, arrays, or beans. Apart from these abstract resolvers, each technology, such as JSP and JSF, and possibly others taking advantage of javax.el, defines technology-specific resolvers.

Jan Luehe: There is also a concept of delayed evaluation of an expression. In the old-style notation, with $ and curly braces surrounding the expression, the expression is compiled when the JSP is compiled, and is evaluated once, when the JSP executes. We also have another way to specify eval-expressions in the JSP and JSF contexts, and that is to use # instead of $. [Editor's note: Eval-expressions are expressions that require evaluation, as opposed to literal expressions.] Such a deferred-evaluation expression is not evaluated until its value is needed. This is especially useful in JSF, where the component life cycle is not tied to page execution. While the latest JSP and JSF specs are backwards compatible with earlier versions, if you want to take advantage of the delayed-evaluation feature, then you must upgrade.

<<  Page 2 of 3  >>


This article is sponsored by the Java Community Process.

Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us