jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sh...@apache.org
Subject cvs commit: jakarta-taglibs/jsptl/doc/web/spel index.html spel.html
Date Thu, 19 Jul 2001 02:09:48 GMT
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 &lt;forEach&gt;, which iterates over most
  -collections and similar objects you'd think to iterate over.  During
  -the iteration -- i.e., inside the &lt;forEach&gt; tag -- you can access
  -the current item of the iteration through the &lt;current&gt; tag.
  +collections and similar objects you'd think to iterate over.  
   &lt;forTokens&gt; 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
   &lt;expressionLanguage&gt;, JSPTL EA1 provides a few other tags to
   facilitate use of expression language.  &lt;expr&gt; prints out the value
  -of a particular expression, optionally formatting it according to the
  -attributes specified along with the tag.  &lt;set&gt; 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 (&lt;%= ... %=&gt;) syntax prints out the value of a
  +expression in the scripting language (typically Java).  &lt;set&gt; 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 &lt;forEach&gt; and
  +&lt;forTokens&gt; 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 (arista@atg.com)</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 &lt; 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 (arista@atg.com)</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 (==, !=, &lt;, &gt;, &lt;=,
  &gt;=).  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>&nbsp;</td>
  <td>&nbsp;</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>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| '!='</b></td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| '&lt;'</b></td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| '&gt;'</b></td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| '&lt;='</b></td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| '&gt;='</b></td>
  </tr>
  
  <tr>
  <td><b>Value</b></td>
  <td>::=</td>
  <td><b>PropertyValue</b></td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| <b>Literal</b></td>
  </tr>
  
  <tr>
  <td><b>PropertyValue</b></td>
  <td>::=</td>
  <td><b>NamedValue</b></td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| <b>PropertyValue</b> '.' <b>Identifier</b></td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</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>&nbsp;</td>
  <td>&nbsp;</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>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| <b>ScopeName</b> ':' <b>StringLiteral</b></td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| ':' (<b>Identifier</b> | <b>StringLiteral</b>)</td>
  </tr>
  
  <tr>
  <td><b>ScopeName</b></td>
  <td>::=</td>
  <td>'page'</td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| 'request'</td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| 'session'</td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| 'app'</td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| 'header'</td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| 'param'</td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</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>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| <b>IntegerLiteral</b></td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| <b>FloatingPointLiteral</b></td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| <b>StringLiteral</b></td>
  </tr>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| <b>NullLiteral</b></td>
  </tr>
  
  <tr>
  <td><b>BooleanLiteral</b></td>
  <td>::=</td>
  <td>'true'</td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| 'false'</td>
  </tr>
  
  <tr valign="top">
  <td><b>StringLiteral</b></td>
  <td>::=</td>
  <td>'([^'\]|\'|\\)*'</td>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| "([^'\]|\'|\\)*"</td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</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>&nbsp;</td>
  <td>&nbsp;</td>
  <td>| (["+","-"])? "." (["0"-"9"])+ (["e","E"] (["+","-"])? (["0"-"9"])+)?</td>
  </tr>
  <tr>
  <td>&nbsp;</td>
  <td>&nbsp;</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. &amp;&amp;), 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>&nbsp;</td>
  
  <td><pre>
  eq
  ne
  lt
  </pre></td>
  
  <td>&nbsp;</td>
  
  <td><pre>
  gt
  le
  ge
  </pre></td>
  
  <td>&nbsp;</td>
  
  <td><pre>
  true
  false
  null
  </pre></td>
  
  <td>&nbsp;</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 &gt;, &lt;, &gt;=, &lt;=</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>
  &lt;mytags:if test="$bean1.a &lt; 3" /&gt;
  </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>
  &lt;mytags:if test="true" /&gt;
  </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>
  &lt;mytags:price price="\$3.95" /&gt;
  </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>
  
  
  

Mime
View raw message