On 8/22/2011 3:43 PM, Mark Thomas wrote:
> On 18/08/2011 22:37, Kin-man Chung wrote:
>> On 08/18/11 14:00, Mark Thomas wrote:
>>> I think this could cause problems.
>>>
>>> Consider the following:
>>>
>>> String input=...
>>> ELProcessor.getValue(input);
>>>
>>> Assuming ${...} can potentially change the return value. With the
>>> automatic bracketing there is no way to pass a literal to
>>> ELProcessor.getValue() and guarantee to get the same literal value back.
>>>
>> Currently you can specify a literal string inside ${...}, like ${'abc'},
>> so theoretically, with automatic bracketing, you can write
>> elProcessor.getValue("'abc'")
>> to pass a literal.
> That makes sense. I was thinking more that the brackets would be
> optional rather than never provided. If the brackets are never required
> then this would work.
Yes, the outer expression need not have brackets.
>> Since we are defining the API for the stand-alone EL, we can set the
>> rules. Would it be less confusing if we limit the expressions in
>> getValue to whatever is allowed in "${...}, and disallow composite
>> expressions (including string literals)?
> Yes, because then the brackets are never required.
>
>> I think we should also add a string concat operator in EL, so that we
>> can do all the things inside ${...} and never need to use composite
>> expressions.
> Even better. Would that make deprecating composite expressions possible?
> (Not that we could ever get rid of them without breaking backwards
> compatibility.)
But, the expressions inside the composite expressions can still have
brackets for backwards compatibility.
Ramesh
> Mark
>