EL Context Framework Design

Motivation

In EL expressions, user and system-defined symbols can be used be used to store and retrieve values as well as point to methods that can be called. For example, the following expression references a property on some object:

#{object.property}

In JSP 2.1/Faces 1.2, the job resolving 'object' and 'property' to values that can be used in evaluating the expression is delegated to an API defined in the Unified EL specification. The root of the API is an class called 'ELContext'. Each implementer of Unified EL can create and populate one or more ELContext object for use in evaluating expressions.

This document lays out the design of a 'design-time framework' to allow tooling that supports technologies that use Unified EL. The emphasis is on supporting JSF and JSP technologies. An effort is also made to remain as backward-compatible with previous tooling as possible without shackling new design.

Restatement of Requirements

There are three major user-stakeholders in this framework. The first is Developer (specialized as JSFDeveloper for JSF tooling. Developer needs to be able to support EL at design-time any place they may use it at runtime. This user also needs a way to install additional support for dependent behaviour for things like third-party libraries.

The second stakeholder is LibraryDeveloper. LibraryDeveloper classifies any users who wishes to have a library that uses Unified EL to be supported by the tooling. In JSP an example of LibraryDeveloper is anyone creating JSP tag libraries; in JSF a specialized example is the JSFComponentLibraryDeveloper. This user needs to be able to add additional support for their library to default framework behaviour.

The third user-stakeholder is ToolsDeveloper. ToolsDeveloper uses the tooling to create specialized tooling that needs to support EL technologies. This user needs to be able to modify any default behaviour to suit specialization to the standard technologies being supporting by the tooling.

Within this context, framework design goals will emphasize the following requirements:

• The framework must be flexible enough to allow each web application (as defined at design time by a dynamic web project rooted in an IProject) to have entirely different symbol resolution in different application contexts. This supports the needs of ToolsDeveloper. For example, Faces 1.2 supports two different ELResolvers depending on where an expression is being resolved.

• The framework must allow third parties to modify the way symbols are resolved in each of the possible application contexts. This supports the needs LibraryDeveloper.

• The framework must provide a simple but comprehensive way for JSFDeveloper to manage these new behaviors on each web application within the constraints of providing correct design time behavior. This includes managing third-party contributions and the ability to enable or disable functionality in ways that match what could happen at runtime.