The JSF/JSP EL mess


Its a known fact that SUN messed up very badly with the design of Expression Language. Its quite strange to imagine that they persisted with different syntaxes for EL within JSF and JSP even though both of them were getting finalized concurrently. I have been looking for reasonable justification for the same. Not that i have found any yet, but still i am putting down SUN’s efforts at it here. Its a copy from the JEE 5 tutorial. See if you get convinced.

JSP supports a simple equest/response life cycle, during which a page is executed and the HTML markup is rendered immediately. Therefore, the simple, read-only expression language offered by JSP 2.0 was well suited to the needs of JSP applications.
JavaServer Faces technology, on the other hand, features a multi-phase life cycle designed to support its sophisticated UI component model, which allows for converting and validating component data, propagating component data to objects, and handling component events. To facilitate these functions, JavaServer Faces technology introduced its own expression language that included the following functionality:

  • Deferred evaluation of expressions
  • The ability to set data as well as get data
  • The ability to invoke methods.

These two expression languages have been unified for a couple reasons.

  1. One reason is so that page authors can mix JSP content with JavaServer Faces tags without worrying about conflicts caused by the different life cycles these technologies support.
  2. Another reason is so that other JSP-based technologies could make use of the additional features similarly to the way JavaServer Faces UNIFIED EXPRESSION LANGUAGE technology uses them. In fact, although the standard JSP tags and static content continue to use only those features present in JSP 2.0, authors of JSP custom tags can create tags that take advantage of the new set of features in the unified expression language.

To summarize, the new, unified expression language allows page authors to use simple expressions to perform the following tasks:

  • Dynamically read application data stored in JavaBeans components, various data structures, and implicit objects.
  • Dynamically write data—such as user input into forms—to JavaBeans components.
  • Invoke arbitrary static and public methods
  • Dynamically perform arithmetic operations.

The unified EL also allows custom tag developers to specify which of the following kinds of expressions that a custom tag attribute will accept:

  • Immediate evaluation expressions or deferred evaluation expressions. An immediate evaluation expression is evaluated immediately by the JSP engine. A deferred evaluation expression can be evaluated later by the underlying technology using the expression language.
  • Value expression or method expression. A value expression references data, whereas a method expression invokes a method.
  • Rvalue expression or Lvalue expression. An rvalue expression can only read a value, whereas an lvalue expression can both read and write that value to an external object.

Finally, the unified EL also provides a pluggable API for resolving expressions so that application developers can implement their own resolvers that can handle expressions not already supported by the unified EL.

Do you accept this argument?

8 comments

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s