Provides the API for the Unified Expression Language shared by
the JSP 2.1 and JSF 1.2 technologies.
The Expression Language (EL) is a simple language designed to satisfy
the specific needs of web application developers. It is currently defined
in its own specification document within the JavaServer Pages (tm) (JSP)
2.1 specification, but does not have any dependencies on any portion
of the JSP 2.1 specification. It is intended for general use outside of
the JSP and JSF specifications as well.
This package contains the classes and interfaces that describe
and define the programmatic access to the Expression Language engine. The API
is logically partitioned as follows:
An important goal of the EL is to ensure it can be used in
a variety of environments. It must therefore provide enough flexibility
to adapt to the specific requirements of the environment where it is
being used.
Class ELContext is what links
the EL with the specific environment where it is being used.
It provides
the mechanism through which all relevant context for creating or
evaluating an expression is specified.
Creation of ELContext objects is controlled through
the underlying technology. For example, in JSP, the
JspContext.getELContext() factory method is used.
Some technologies provide the ability to add an ELContextListener
so that applications and frameworks can ensure their own context objects
are attached to any newly created ELContext.
At the core of the Expression Language is the notion of an expression
that gets parsed according to the grammar defined by the Expression Language.
There are two types of expressions defined by the EL: value expressions
and method expressions. A ValueExpression such as
"${customer.name}" can be used either
as an rvalue (return the value associated with property name
of the model object customer) or as an lvalue
(set the value of the property name of the model object
customer).
A MethodExpression such as
"${handler.process}" makes it possible to invoke a method
(process) on a specific model object (handler).
All expression classes extend the base class Expression , making them
serializable and forcing them to implement equals() and
hashCode(). Morevover, each method on these expression classes
that actually evaluates an expression receives a parameter
of class ELContext ,
which provides the context required to evaluate the expression.
An expression is created through the ExpressionFactory class.
The factory provides two creation methods; one for each type of expression
supported by the EL.
To create an expression, one must provide an ELContext ,
a string representing
the expression, and the expected type (ValueExpression) or signature
(MethodExpression).
The ELContext provides the context necessary to parse an expression.
Specifically, if the expression uses an EL function
(for example ${fn:toUpperCase(customer.name)}) or an
EL variable, then
FunctionMapper and VariableMapper
objects must be available within the ELContext so that EL functions and
EL variables are properly mapped.
Tools can easily obtain more information about resolvable model objects and their
resolvable properties by calling
method getFeatureDescriptors on the ELResolver. This method exposes objects
of type java.beans.FeatureDescriptor, providing all information of interest
on top-level model objects as well as their properties.
If an EL expression uses a function
(for example ${fn:toUpperCase(customer.name)}), then a
FunctionMapper
object must also be specified within the ELContext.
The FunctionMapper is responsible to map
${prefix:name()} style functions to
static methods that can execute the specified functions.
Just like FunctionMapper provides
a flexible mechanism to add functions to the EL, VariableMapper
provides a flexible mechanism to support the notion of
EL variables.
An EL variable does not directly refer to a model object that can then
be resolved by an ELResolver. Instead, it refers to an EL
expression. The evaluation of that EL expression gives the EL variable
its value.
For example, in the following code snippet
<h:inputText value="#{handler.customer.name}"/>
handler refers to a model object that can be resolved by an EL Resolver.
item is an EL variable because it does not refer directly to a model
object. Instead, it refers to another EL expression, namely a
specific item in the collection referred to by the EL expression
#{model.list}.
Assuming that there are three elements in ${model.list}, this means
that for
each invocation of <h:inputText>, the following information
about item must be preserved in the VariableMapper :
first invocation: item maps to first element in ${model.list}
second invocation: item maps to second element in ${model.list}
third invocation: item maps to third element in ${model.list}
VariableMapper provides the mechanisms required to allow the mapping
of an EL variable to the EL expression from which it gets its value.
The Expression Language (EL) is a simple language designed to satisfy the specific needs of web application developers. It is currently defined in its own specification document within the JavaServer Pages (tm) (JSP) 2.1 specification, but does not have any dependencies on any portion of the JSP 2.1 specification. It is intended for general use outside of the JSP and JSF specifications as well.
This package contains the classes and interfaces that describe and define the programmatic access to the Expression Language engine. The API is logically partitioned as follows:
EL Context
An important goal of the EL is to ensure it can be used in a variety of environments. It must therefore provide enough flexibility to adapt to the specific requirements of the environment where it is being used.
Class ELContext is what links the EL with the specific environment where it is being used. It provides the mechanism through which all relevant context for creating or evaluating an expression is specified.
Creation of
ELContextobjects is controlled through the underlying technology. For example, in JSP, theJspContext.getELContext()factory method is used.Some technologies provide the ability to add an ELContextListener so that applications and frameworks can ensure their own context objects are attached to any newly created
ELContext.Expression Objects
At the core of the Expression Language is the notion of an expression that gets parsed according to the grammar defined by the Expression Language.
There are two types of expressions defined by the EL: value expressions and method expressions. A ValueExpression such as
"${customer.name}"can be used either as an rvalue (return the value associated with propertynameof the model objectcustomer) or as an lvalue (set the value of the propertynameof the model objectcustomer).A MethodExpression such as
"${handler.process}"makes it possible to invoke a method (process) on a specific model object (handler).All expression classes extend the base class Expression , making them serializable and forcing them to implement
equals()andhashCode(). Morevover, each method on these expression classes that actually evaluates an expression receives a parameter of class ELContext , which provides the context required to evaluate the expression.Creation of Expressions
An expression is created through the ExpressionFactory class. The factory provides two creation methods; one for each type of expression supported by the EL.
To create an expression, one must provide an ELContext , a string representing the expression, and the expected type (
ValueExpression) or signature (MethodExpression). TheELContextprovides the context necessary to parse an expression. Specifically, if the expression uses an EL function (for example${fn:toUpperCase(customer.name)}) or an EL variable, then FunctionMapper and VariableMapper objects must be available within theELContextso that EL functions and EL variables are properly mapped.Resolution of Model Objects and their Properties
Through the ELResolver base class, the EL features a pluggable mechanism to resolve model object references as well as properties of these objects.
The EL API provides implementations of
ELResolversupporting property resolution for common data types which include arrays ( ArrayELResolver ), JavaBeans ( BeanELResolver ),Lists ( ListELResolver ),Maps ( MapELResolver ), andResourceBundles ( ResourceBundleELResolver ).Tools can easily obtain more information about resolvable model objects and their resolvable properties by calling method
getFeatureDescriptorson theELResolver. This method exposes objects of typejava.beans.FeatureDescriptor, providing all information of interest on top-level model objects as well as their properties.EL Functions
If an EL expression uses a function (for example
${fn:toUpperCase(customer.name)}), then a FunctionMapper object must also be specified within theELContext. TheFunctionMapperis responsible to map${prefix:name()}style functions to static methods that can execute the specified functions.EL Variables
Just like FunctionMapper provides a flexible mechanism to add functions to the EL, VariableMapper provides a flexible mechanism to support the notion of EL variables.
An EL variable does not directly refer to a model object that can then be resolved by an
ELResolver. Instead, it refers to an EL expression. The evaluation of that EL expression gives the EL variable its value.For example, in the following code snippet
handlerrefers to a model object that can be resolved by an EL Resolver.However, in this other example:
itemis an EL variable because it does not refer directly to a model object. Instead, it refers to another EL expression, namely a specific item in the collection referred to by the EL expression#{model.list}.
Assuming that there are three elements in
${model.list}, this means that for each invocation of<h:inputText>, the following information aboutitemmust be preserved in the VariableMapper :VariableMapperprovides the mechanisms required to allow the mapping of an EL variable to the EL expression from which it gets its value.