Expression Language 2.2
|
|
|
Expression Language release 2.2
Literal-expression
A literal-expression does not use the ${expr} or #{expr} constructs, and simply evaluates to the text of the expression, of type String. Upon evaluation, an expected type of something other than String can be provided. Sample literalexpressions are shown in the table below.
| Expression | Expected Type | Result |
|---|---|---|
| Hello World ! | String | Hello World ! |
| true | Boolean | Boolean.TRUE |
To generate literal values that include the character sequence "${" or “#{“, the developer can choose to use a composite expression as shown here:
- ${'${'}exprA}
- #{'#{'}exprB}The resulting values would then be the strings ${exprA} and #{exprB}.
- \${exprA}
- \#{exprB}
The resulting values would again be the strings ${exprA} and #{exprB}. A literal-expression can be used anywhere a value expression can be used. A literalexpression can also be used as a method expression that returns a non-void return�value. The standard EL coercion rules (see Section 1.18, “Type Conversion”) then�apply if the return type of the method expression is not java.lang.String.
Composite expressions
The EL also supports composite expressions, where multiple EL expressions are grouped together. With composite expressions, eval-expressions are evaluated from left to right, coerced to Strings (according to the EL type conversion rules), and concatenated with any intervening literal-expressions.
For example, the composite expression “${firstName} ${lastName}” is composed of three EL expressions: eval-expression “${firstName}”, literalexpression “ “, and eval-expression “${lastName}”.
Once evaluated, the resulting String is then coerced to the expected type, according to the EL type conversion rules. A sample composite expression is shown below
| Expression | Expected Type | Result |
|---|---|---|
Welcome |
String |
Welcome John Doe to our |
It is illegal to mix ${} and #{} constructs in a composite expression.
Literals
There are literals for boolean, integer , floating point, string, and null in an evalexpression.
| Type | Description |
|---|---|
|
String |
With single and double quotes - " is escaped as \", ' is escaped as \', and \ is escaped as \\. Quotes only need to be escaped in a string value enclosed
|
|
Boolean |
true and false |
| Integer |
As defined by the IntegerLiteral construct : IntegerLiteral ::= [�0’-’9’]+ |
| Float |
As defined by the FloatingPointLiteral construct :
FloatingPointLiteral::= ([�0’-’9’])+ �.’ ([�0’-’9’])* Exponent?
|
| Null | null |
Enums
The Unified EL supports Java SE 5 enumerated types. Coercion rules for dealing with enumerated types are included in the following section. Also, when referring to values that are instances of an enumerated type from within an EL expression, use the literal string value to cause coercion to happen via the below rules.
For example, Let’s say we have an enum called Suit that has members Heart, Diamond, Club, and Spade. Furthermore, let’s say we have a reference in the EL, mySuit, that is a Spade.
If you want to test for equality with the Spade enum, you would say ${mySuit == ’Spade’} . The type of the mySuit will trigger the invocation of Enum.valueOf(Suit.class, ’Spade’) .
Tags: type , expression , composite , string , values , escaped , conversion