shawn 01/07/18 19:09:48
Modified: jsptl/doc/web GettingStarted.html Overview.html index.html
Added: jsptl/doc/web/spel index.html spel.html
Log:
Updated documentation (with requests from Pierre).
Revision Changes Path
1.2 +20 -15 jakarta-taglibs/jsptl/doc/web/GettingStarted.html
Index: GettingStarted.html
===================================================================
RCS file: /home/cvs/jakarta-taglibs/jsptl/doc/web/GettingStarted.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- GettingStarted.html 2001/07/08 16:27:32 1.1
+++ GettingStarted.html 2001/07/19 02:09:48 1.2
@@ -116,11 +116,11 @@
<p>Before using <tt>jx</tt>, you should decide which of the experimental
expression languages you wish to use. (JSPTL EA1 supports "pluggable"
expression languages to facilitate experimentation.) We recommend
-beginning with the "simplest possible expression language" (SPEL) and
-determining if it meets your needs. If you want to experiment with more
-complex expressions, you can also use the provide "JPath" language. And
-you can always plug in your own expressions using the mechanisms described
-below.</p>
+beginning with the <a href="spel">"simplest possible expression language"
+(SPEL)</a> and determining if it meets your needs. If you want to experiment
+with more complex expressions, you can also use the provide "JPath"
+language. And you can always plug in your own expressions using the
+mechanisms described below.</p>
<p>The default expression language for a web application is configured by
setting the servlet context parameter
@@ -164,9 +164,7 @@
<dt><b>Iteration</b></dt>
<dd>The core iteration tag is <forEach>, which iterates over most
-collections and similar objects you'd think to iterate over. During
-the iteration -- i.e., inside the <forEach> tag -- you can access
-the current item of the iteration through the <current> tag.
+collections and similar objects you'd think to iterate over.
<forTokens> lets you iterate over tokens in a <tt>String</tt>
object; it lets you specify the <tt>String</tt> and the delimiters.</dd>
@@ -184,10 +182,11 @@
<dd>We described the EL support in JSPTL EA1 above. In addition to
<expressionLanguage>, JSPTL EA1 provides a few other tags to
facilitate use of expression language. <expr> prints out the value
-of a particular expression, optionally formatting it according to the
-attributes specified along with the tag. <set> lets you set a
-scoped attribute (e.g., a value in the request, page, session, or
-application scopes) with the value of an expression.</dd>
+of a particular expression in the current EL, similar to the way that the
+scriptlet expression (<%= ... %=>) syntax prints out the value of a
+expression in the scripting language (typically Java). <set> lets
+you set a scoped attribute (e.g., a value in the request, page, session,
+or application scopes) with the value of an expression.</dd>
</dl>
@@ -204,9 +203,15 @@
conditional tag by merely implementing a single method that returns a
<tt>boolean</tt> value correspondent with your tag's desired conditional
behavior; also, this base class promotes JSPTL's recommended model of
-conditional-tag design. Similarly,
-<tt>javax.servlet.jsp.IteratorTagSupport</tt> lets you easily implement
-iteration tags and helps those tage operate under JSPTL's conventions.</p>
+conditional-tag design.</p>
+
+<p>Similarly, <tt>javax.servlet.jsp.IteratorTagSupport</tt> lets you
+easily implement iteration tags. The handlers for the <forEach> and
+<forTokens> tags extend this class and thus implement the
+<tt>javax.servlet.jsp.IteratorTag</tt> interface, which provides a
+well-defined mechanism for iteration tags to communicate with custom
+subtags you can write. See the "jsptl-examples" application for one
+example of how you might use such custom subtags.</p>
</body>
</html>
1.3 +3 -0 jakarta-taglibs/jsptl/doc/web/Overview.html
Index: Overview.html
===================================================================
RCS file: /home/cvs/jakarta-taglibs/jsptl/doc/web/Overview.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Overview.html 2001/07/18 22:39:07 1.2
+++ Overview.html 2001/07/19 02:09:48 1.3
@@ -57,6 +57,9 @@
a variety of ELs. Tell us what you feel is important for that EL, and feel free
to implement one that others can experiment with. The goal is to select a single
EL once the JSPTL spec is ready for Community Review.</p>
+<p>Early Access one contains several candidate Expression Languages. For
+ more information on the "SPEL" (Simplest Possible Expression Language)
+ language, you can read the <a href="spel">SPEL Overview</a>.</p>
<h3>Tag Collaboration</h3>
<p>Tags usually collaborate with their environment in implicit and/or explicit
ways. Implicit collaboration is done via a well defined interface that allows
1.2 +9 -1 jakarta-taglibs/jsptl/doc/web/index.html
Index: index.html
===================================================================
RCS file: /home/cvs/jakarta-taglibs/jsptl/doc/web/index.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.html 2001/07/08 16:27:32 1.1
+++ index.html 2001/07/19 02:09:48 1.2
@@ -42,7 +42,15 @@
<li><a
href="ExpressionLanguageSupport_FunctionalDescription_2_EA1.html">
Expression-language support</a></li>
<li><a href="ExpressionTags_FunctionalDescription_1_EA1.html">
- Expression-language tags</a></li>
+ Expression-language tags</a>
+ <ul>
+ <li>The
+ <a href="spel">
+ Simplest Possible Expression Language
+ (SPEL) </a>
+ </li>
+ </ul>
+ </li>
</ul>
</li>
</ul>
1.1 jakarta-taglibs/jsptl/doc/web/spel/index.html
Index: index.html
===================================================================
<html>
<head><title>SPEL Implementation</title></head>
<body>
<h1>SPEL Implementation</h1>
<h4>Nathan Abramson ([EMAIL PROTECTED])</h4>
<h2>Overview</h2>
<p>This distribution contains an implementation of the <a
href="spel.html">Simplest Possible Expression Language (SPEL) for the
JSPSTL</a>. In addition to the implementation, the distribution
contains regression tests for the parser and evaluator, and a simple
performance test.
<p>The distribution contains the following directories and files:
<ul>
<li><b>doc/</b> - documentation
<li><b>src/</b> - all source files
<li><b>lib/classes.jar</b> - compiled classes
</ul>
<h2>Implementation Notes</h2>
<ul>
<li>The class files are found in the package
<b>org.apache.taglibs.jsptl.lang.spel</b>.
<li>The class implementing ExpressionEvaluator is
<b>org.apache.taglibs.jsptl.lang.spel.Evaluator</b>
<li>The implementation assumes that the ExpressionEvaluator interface
is found at <b>javax.servlet.jsptl.ExpressionEvaluator</b>, with the
following definition (taken from Shawn's implementation):
<ul><pre>
public String validate(String attributeName,
String expression);
public Object evaluate(String attributeName,
String expression,
Class expectedType,
Tag tag,
PageContext pageContext)
throws JspException;
</pre></ul>
<p>If this is not the package or definition of the ExpressionEvaluator
interface, the appropriate changes should be made to the <a
href="../src/org/apache/taglibs/jsptl/lang/spel/Evaluator.java">src/org/apache/taglibs/jsptl/lang/spel/Evaluator.java</a>
source file. In any case, the <a
href="../src/javax/servlet/jsptl/ExpressionEvaluator.java">ExpressionEvaluator
implementation</a> should be removed from the distribution, and the
distribution should be compiled against the "real" implementation of
that class.
<li>The parser was generated using <a
href="http://www.webgain.com/products/metamata/java_doc.html";>JavaCC</a>.
The parser definition is found in <a
href="../src/org/apache/taglibs/jsptl/lang/spel/SpelParser.jj">src/org/apache/taglibs/jsptl/lang/spel/SpelParser.jj</a>,
and all files generated by JavaCC are placed into the
org.apache.taglibs.jsptl.lang.spel.parser package. Note that JavaCC is not
required to compile the SPEL implementation - it is only needed if the
grammar in the SpelParser.jj file changes.
<li>JavaCC 1.0 was used to generate the parser. If desired, the most
recent version of JavaCC can be used to regenerate the parser, but the
<a href="#regressionTests">regression tests</a> should then be run to
make sure the behavior hasn't changed.
<li>All localizable error messages are stored in the <a
href="../src/org/apache/taglibs/jsptl/lang/spel/Resources.properties">src/org/apache/taglibs/jsptl/lang/spel/Resources.properties</a>
file. This file must be copied into the final distribution with the
generated class files.
</ul>
<a name="regressionTests"><h2>Regression Tests</h2></a>
<p>There are two sets of automated regression tests - the first tests
the parser, and the second tests the full evaluator. In both cases,
the tester takes an input file containing expressions to be parsed or
evaluated, processes each expression, and writes the results or errors
to an output file. The output file can then be compared against an
expected output file to see if any regression has occurred.
<p>In both cases, input lines that are blank or start with "#" are
copied to the output file without interpretation. This allows
comments to appear in the output file, which can aid in debugging.
<h4>Parser tests</h4>
<p>The parser test input file is found at <a
href="../src/org/apache/taglibs/jsptl/lang/spel/test/parserTests.txt">src/org/apache/taglibs/jsptl/lang/spel/test/parserTests.txt</a>.
Each line represents an expression to be parsed - the expression is
parsed, and printed back out in the evaluator's "canonical form". For
example, in the canonical form, all Strings are enclosed by double
quotes, all names are prefixed by a scope operator ":", etc.
<p>The expected outputs are found at <a
href="../src/org/apache/taglibs/jsptl/lang/spel/test/parserTestsExpectedOutput.txt">src/org/apache/taglibs/jsptl/lang/spel/test/parserTestsExpectedOutput.txt</a>
<p>The parser tests can be run like this:
<ul><pre>
java org.apache.taglibs.jsptl.lang.spel.test.ParserTest {inputFile} {outputFile}
[{expectedOutputFile}]
</pre></ul>
The {expectedOutputFile} is optional - if supplied, the test will
compare the ouput file with the expected output file and print whether
the test passed or failed.
<h4>Evaluation tests</h4>
<p>For the evaluation test, a "dummy" PageContext was created
containing some beans with properties in various scopes. That
PageContext is created in the "createTestContext" method of <a
href="../src/org/apache/taglibs/jsptl/lang/spel/test/EvaluationTest.java">src/org/apache/taglibs/jsptl/lang/spel/test/EvaluationTest.java</a>.
<p>The evaluation test input file is found at <a
href="../src/org/apache/taglibs/jsptl/lang/spel/test/evaluationTests.txt">src/org/apache/taglibs/jsptl/lang/spel/test/evaluationTests.txt</a>.
Each line represents an expression to be parsed, followed by a line
specifying the expected type - the expression is parsed, and the
resulting value is printed along with its class.
<p>The expected outputs are found at <a
href="../src/org/apache/taglibs/jsptl/lang/spel/test/evaluationTestsExpectedOutput.txt">src/org/apache/taglibs/jsptl/lang/spel/test/evaluationTestsExpectedOutput.txt</a>
<p>The evaluation tests can be run like this:
<ul><pre>
java org.apache.taglibs.jsptl.lang.spel.test.EvaluationTest {inputFile} {outputFile}
[{expectedOutputFile}]
</pre></ul>
The {expectedOutputFile} is optional - if supplied, the test will
compare the ouput file with the expected output file and print whether
the test passed or failed.
<a name="optimizations"><h2>Optimizations</h2></a>
<p>Because expression evaluation could conceivably make up a large
portion of a JSP's rendering time, a great deal of emphasis was placed
on performance. The following performance optimizations were used:
<ul>
<p><li>Parsed expressions are cached, so that each expression is
parsed only once. To avoid synchronization bottlenecks, the cache is
only synchronized around determining if an expression is in the cache,
and putting a parsed expression into the cache. This means that two
threads could both end up parsing and caching the same uncached
expression at the same time, but the result of this is harmless. This
caching happens in the Evaluator class.
<p><li>The Evaluator class is also responsible for parsing literals
(expressions not starting with "$"). The results of these parsings
are also cached, but in this case the key is {expression,
expectedType}. Rather than creating an actual key class (which would
require object creations for each lookup), the tuple key is simulated
by having two levels of caches: expected type -> expression -> parsed
expression.
<p><li>The mapping from {class,propertyName} to PropertyDescriptor is
cached by the BeanInfoManager. The PropertyDescriptors are used by
the "{bean}.{property}" construct.
<p><li>In cases where a primitive type needs to be wrapped in an
object (such as the final casting from expression result to expected
type), the PrimitiveObjects class is used to do the wrapping. This
class precalculates the wrappings for bytes and chars with values from
0-255, and shorts, ints, and longs with values from -1000 to 1000.
Wrapped values in those ranges will not require any object creations
to represent their primitive values.
</ul>
<a name="performanceTests"><h2>Performance Tests</h2></a>
<p>The distribution includes a single performance test which evaluates
an expression many times. The expression is:
<ul><pre>
session:bean1a.bean1.int1 < 24
</pre></ul>
<p>To test for synchronization bottlenecks, the test spawns several
threads which simultaneously evaluate the expression many times.
<p>The test then runs again, but evaluates the expression "by hand"
using direct API calls - i.e.,
pageContext.getAttribute(...).getBean1().getInt1 () < 24. So the
performance test essentially determines the cost of using an
expression instead of an rtexprvalue.
<p>The test is run like this:
<ul><pre>
org.apache.taglibs.jsptl.lang.spel.test.PerformanceTest {#threads}
{#iterations/thread}
</pre></ul>
<p>The initial results are encouraging - running 20 threads over
100000 iterations/thread, a ThinkPad 600E could do ~50000
iterations/second using the evaluator, and ~110000 iterations/second
using the API calls. So using the API calls in this example is only
twice as fast as using the evaluator, which means that the expression
language introduces a significant, but not severe performance penalty.
<h4><i>$Change: 181170 $$DateTime: 2001/06/26 08:09:32 $$Author: shawn $</i></h4>
</html>
1.1 jakarta-taglibs/jsptl/doc/web/spel/spel.html
Index: spel.html
===================================================================
<html>
<head><title>Simplest Possible Expression Language (SPEL) for
JSPSTL</title></head>
<body>
<h1>Simplest Possible Expression Language (SPEL) for JSPSTL</h1>
<h4>Nathan Abramson ([EMAIL PROTECTED])</h4>
<h2>Overview</h2>
<p>The SPEL is designed to be the simplest possible JSPSTL expression
language that is still useful. The only required features of the SPEL
are:
<ul>
<li>notion of scope (page, request, session, app)
<li>nested attributes
<li>relational operators
</ul>
<p>The idea is to design a language that will eventually grow, keeping
in mind that future versions of the language should be backwards
compatible with this version of the SPEL.
<h2>Syntax</h2>
<p>The syntax is extremely simple. Attributes are accessed by name,
with an optional scope ("page:", "request:", "session:", "app:").
Properties of attributes are accessed using the "." operator, and may
be nested arbitrarily. Attribute and property names must be java
identifiers, unless they are quoted. Relational comparisons are
allowed using the relational operators (==, !=, <, >, <=,
>=). Comparisons may be made against other values, or against
boolean, String, integer, or floating point literals.
<p>The following are the constructs supported by the SPEL:
<table>
<tr>
<td><b>Expression</b></td>
<td>::=</td>
<td><b>Value</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| <b>RelationalExpression</b></td>
</tr>
<tr>
<td><b>RelationalExpression</b></td>
<td>::=</td>
<td><b>Value RelOp Value</b></td>
</tr>
<tr>
<td><b>RelOp</b></td>
<td>::=</td>
<td><b>'=='</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| '!='</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| '<'</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| '>'</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| '<='</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| '>='</b></td>
</tr>
<tr>
<td><b>Value</b></td>
<td>::=</td>
<td><b>PropertyValue</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| <b>Literal</b></td>
</tr>
<tr>
<td><b>PropertyValue</b></td>
<td>::=</td>
<td><b>NamedValue</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| <b>PropertyValue</b> '.' <b>Identifier</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| <b>PropertyValue</b> '.' <b>StringLiteral</b></td>
</tr>
<tr>
<td><b>NamedValue</b></td>
<td>::=</td>
<td><b>ScopedIdentifier</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| <b>Identifier</b></td>
</tr>
<tr>
<td><b>ScopedIdentifier</b></td>
<td>::=</td>
<td><b>ScopeName</b> ':' <b>Identifier</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| <b>ScopeName</b> ':' <b>StringLiteral</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| ':' (<b>Identifier</b> | <b>StringLiteral</b>)</td>
</tr>
<tr>
<td><b>ScopeName</b></td>
<td>::=</td>
<td>'page'</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| 'request'</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| 'session'</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| 'app'</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| 'header'</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| 'param'</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| 'paramvalues'</td>
</tr>
<tr>
<td><b>Identifier</b></td>
<td>::=</td>
<td><i>Java language identifier</i></td>
</tr>
<tr>
<td><b>Literal</b></td>
<td>::=</td>
<td><b>BooleanLiteral</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| <b>IntegerLiteral</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| <b>FloatingPointLiteral</b></td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| <b>StringLiteral</b></td>
</tr>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| <b>NullLiteral</b></td>
</tr>
<tr>
<td><b>BooleanLiteral</b></td>
<td>::=</td>
<td>'true'</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| 'false'</td>
</tr>
<tr valign="top">
<td><b>StringLiteral</b></td>
<td>::=</td>
<td>'([^'\]|\'|\\)*'</td>
<tr>
<td> </td>
<td> </td>
<td>| "([^'\]|\'|\\)*"</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>i.e., a string of any characters enclosed by single or double
quotes, where \ is used to escape ', ", and \.</td>
</tr>
<tr>
<td><b>IntegerLiteral</b></td>
<td>::=</td>
<td>["+","-"] ["1"-"9"] (["0"-"9"])*</td>
</tr>
<tr>
<td><b>FloatingPointLiteral</b></td>
<td>::=</td>
<td> (["+","-"])? (["0"-"9"])+ "." (["0"-"9"])* (["e","E"] (["+","-"])?
(["0"-"9"])+)?</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| (["+","-"])? "." (["0"-"9"])+ (["e","E"] (["+","-"])? (["0"-"9"])+)?</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td>| (["+","-"])? (["0"-"9"])+ ["e","E"] (["+","-"])? (["0"-"9"])+</td>
</tr>
<tr>
<td><b>NullLiteral</b></td>
<td>::=</td>
<td>'null'</td>
</tr>
</table>
<p>Notes:
<ul>
<li>An identifier is constrained to be a Java identifier - i.e., no
"-", no "/", etc. without quoting. Eventually this may be expanded,
but this is the minimum.
<li>A String only recognizes a limited set of escape sequences, and \
may not appear unescaped. This may eventually be expanded, but once
again, this is the minimum.
<li>The definitions for integer and floating point literal are pretty
much taken from the Java definitions.
<li>The relational operator for equality is "==" (double equals).
This is to be more Java-like, but is it the best idea?
<li>There are no logical operators (and, or, not). Designing these
introduces the notion of grouping (parentheses) and order of
precedence, and also deciding what the actual operators should be (and
vs. &&), which also introduces the notion of reserved words.
It is possible that keeping these out severely limits the usefulness
of the language. Should they be introduced?
</ul>
<h2>Reservered Words</h2>
<p>The following words are reserved for the language and should not be
used as identifiers without being quoted.
<ul><table>
<tr valign="top">
<td><pre>
and
or
not
</pre></td>
<td> </td>
<td><pre>
eq
ne
lt
</pre></td>
<td> </td>
<td><pre>
gt
le
ge
</pre></td>
<td> </td>
<td><pre>
true
false
null
</pre></td>
<td> </td>
<td><pre>
instanceof
</pre></td>
</tr>
</table></ul>
<p>Note that these words may not be in the language now, but they may
be in the future, so developers should avoid using these words now.
<h2>Named Values</h2>
<p>If a named value is specified with a scope of "page", "request",
"session", or "app", its value is the value of that name in the given
scope. If no scope is given, the value is found according to the
rules of PageContext.findAttribute(name).
<p>If a named value is specified with a scope of "header", its value
is obtained by calling HttpServletRequest.getHeader(String).
<p>If a named value is specified with a scope of "param", its value is
obtained by calling ServletRequest.getParameter(String).
<p>If a named value is specified with a scope of "paramvalues", its
value is obtained by calling
ServletRequest.getParameterValues(String).
<p>In any of these cases, if a value is not found, the result is an <a
href="#expressionExceptions">ExpressionException</a>, not "null".
<h2>Property Values</h2>
<p>The expression "value . propertyName" denotes a property
expression. The property is found through introspection by treating
the value as a JavaBean and calling the appropriate setter method. If
the result is a primitive value, the result is converted to the Object
equivalent of the primitive.
<ul>
<li>It is an error if the bean value is null.
<li>It is an error if the specified property is not found in the bean.
<li>It is an error if calling the getter results in an error.
</ul>
<p>Note that these error conditions might be relaxed in the future,
but for now they are as strict as possible.
<p>In the future, the "." operator might be extended to interpret
other name/value collections, such as Maps, but for now this is not
the case. Note that in the future, the "Map behavior" might happen
automatically, so JavaBeans should avoid implementing "java.util.Map"
to avoid having their behavior change in the future.
<h2>Type Conversion</h2>
<p>Every expression is evaluated in the context of an "expected type".
The result of the expression evaluation may not match the expected
type exactly, so the following rules are applied:
<ul>
<li>If the expected type is assignable from the value's type, no
conversion is required.
<li>If the expected type is an Object type and the value is null, no
conversion is required.
<li>If the expected type is a primitive and the value is null, an
error results.
<li>If the expected type is a primitive and the value is the Object
equivalent of that primitive, the Object equivalent is returned.
<li>If the expected type (or its Object equivalent) is a numeric type,
and the value is also a numeric type, the value is converted to the
expected type, even if loss of precision would occur. The numeric
types are: byte, short, int, long, float, double.
<li>Any other condition is an error
</ul>
<h2>Relational Comparisons</h2>
<p>The following rules are applied to evaluate a relational
comparison.
<h3>Rules for == and !=</h3>
<p>The rules for equality are as follows:
<ul>
<li>If both values are null, the values are considered to be equal
<li>If only one value is null, the values are not equal
<li>If both values are the same object, the values are considered to
be equal
<li>If both values are numeric types, then the value with the least
precise type is "cast up" to the type of the other value, and their
values are compared. The order of numeric types from least precise to
most precise is byte, short, int, long, float, double
<li>If leftHandValue.equals(rightHandValue), the values are considered
to be equal
<li>In all other cases, the values are not equal
</ul>
<h3>Rules for >, <, >=, <=</h3>
<p>The rules for ordered comparisons are as follows:
<ul>
<li>If both values are Strings, the Strings are comapared according to
the rules of String.compareTo(String).
<li>If both values are numeric types, then the value with the least
precise type is "cast up" to the type of the other value, and their
values are compared. The order of numeric types from least precise to
most precise is byte, short, int, long, float, double
<li>All other cases result in an error
</ul>
<a name="expressionExceptions"><h2>ExpressionExceptions</h2></a>
<p>The ExpressionException mechanism in the JSPTL is provided as a way
for expression languages to indicate that there was a problem
evaluating an expression, but the problem was small enough that a
default value could be substituted in its place without invoking the
entire JSP error handling mechanism.
<p>The SPEL throws javax.servlet.jsptl.ExpressionException in the
following situations:
<ul>
<li>A NamedValue (e.g., "session:profile") can't be found. If the
specified name is not found in the specified scope, then an
ExpressionException is thrown, not a null value.
<li>A requested property of a bean can't be evaluated, either because:
<ul>
<li>the bean's value is null
<li>the bean does not have the specified property
<li>the bean's property is not readable
<li>there is an error invoking the bean's read method
</ul>
</ul>
<h2>Literals and Delimiter</h2>
<p>The SPEL is responsible for handling both expressions and
literals. Expressions begin with a "$" character. For example:
<ul><pre>
<mytags:if test="$bean1.a < 3" />
</pre></ul>
<p>Any value that does not begin with "$" is treated as a literal that
is parsed to the expected type using the PropertyEditor for the
expected type:
<ul><pre>
<mytags:if test="true" />
</pre></ul>
<p>There may be literal values that start with the "$" character. If
that is the case, the value must be escaped using the "\" character.:
<ul><pre>
<mytags:price price="\$3.95" />
</pre></ul>
<p>If a value starts with "\$", it is treated as a literal value with
the leading "\" removed.
<h4><i>$Change: 181991 $$DateTime: 2001/07/02 16:12:52 $$Author: shawn $</i></h4>
</html>
