javax.servlet.jsp.el.package.html Maven / Gradle / Ivy
Provides the ELResolver classes that define the
object resolution rules that must be supported by a JSP container
with the new unified Expression Language.
The package also defines programmatic access to the old Expression Language
evaluator (pre JSP 2.1).
Please note
that as of JSP 2.1, all classes and interfaces that were in package
javax.servlet.jsp.el have been deprecated in favor of the new unified
Expression Language APIs (javax.el). See the Expression Language
specification document for more details.
While a JSP container must still support the deprecated APIs defined
in javax.servlet.jsp.el, developers should only rely on the
new javax.el APIs
for new development work.
Two ELResolver classes have been added in JSP 2.1 to implement
object resolution rules that must be supported by a JSP container
with the new unified Expression Language:
{@link javax.servlet.jsp.el.ImplicitObjectELResolver} and
{@link javax.servlet.jsp.el.ScopedAttributeELResolver}.
Documentation on the old and deprecated API
The JavaServer Pages(tm) (JSP) 2.0 specification provides a portable
API for evaluating "EL Expressions". As of JSP 2.0, EL expressions can
be placed directly in the template text of JSP pages and tag files.
This package contains a number of classes and interfaces that describe
and define programmatic access to the Expression Language evaluator.
This API can also be used by an implementation of JSP to evaluate the
expressions, but other implementations, like open-coding into Java
bytecodes, are allowed. This package is intended to have no dependencies
on other portions of the JSP 2.0 specification.
Expression Evaluator
Programmatic access to the EL Expression Evaluator is provided
through the following types:
ExpressionEvaluatorExpressionFunctionMapperVariableResolver
An ExpressionEvaluator object can be obtained from a
JspContext object through the getExpressionEvaluator
method. An ExpressionEvaluator encapsulates the EL processor. An EL
expression provided as a String can then be evaluated directly, or it
can be parsed first into an Expression object. The parse
step, can be used to factor out the cost of parsing the expression, or
even the cost of optimizing the implementation.
The parsing of an expression string is done against a target type,
a default prefix (that applies when a function has no prefix), and
a FunctionMapper. The FunctionMapper object
maps a prefix and a local name part into a
java.lang.reflect.Method object.
The interpretation or evaluation of a parsed expression is done
using a VariableResolver object. This object resolves
top level object names into Objects. A VariableResolver
can be obtained from a JspContext object through the
getVariableResolver method.
Exceptions
The ELException exception is used by the expression
language to denote any exception that may arise during the parsing or
evaluation of an expression.
The ELParseException exception is a subclass of
ELException that corresponds to parsing errors
Parsing errors are conveyed as exceptions to simplify the API. It
is expected that many JSP containers will use additional mechanisms to
parse EL expressions and report their errors - a run-time API cannot
provide accurate line-error numbers without additional machinery.
Code Fragment
Below is a non-normative code fragment outlining how the APIs can be used.
// Get an instance of an ExpressionEvaluator
ExpressionEvaluator ee = myJspContext.getExpressionEvaluator();
VariableResolver vr = myJspContext.getVariableResolver();
FunctionMapper fm; // we don't have a portable implementation yet
// Example of compiling an expression. See [ISSUE-2]
// Errors detected this way may have higher quality than those
// found with a simple validate() invocation.
ExpressionCompilation ce;
try {
ce = ee.prepareExpression(expr,
targetClass,
fm,
null // no prefixes
);
} catch (ELParseException e) {
log (e.getMessage());
}
try {
ce.evaluate(vr);
} catch (ElException e) {
log (e);
}