On 08/18/11 14:00, Mark Thomas wrote:
> On 18/08/2011 21:48, Kin-man Chung wrote:
>
>> When evaluating EL expression in ELProcessor, writing the expressions
>> bracketed by #{ and } seems redundant, especially since ${ is treated
>> the same as a #{. I think we can write
>>
>> elProcessor.getValue("foo.bar");
>>
>> instead of
>>
>> elProcessor.getValue("#{foo.bar}");
>>
>> The only thing this would be a problem is the composite expressions,
>> such as
>>
>> "abc#{foo.bar}xyz#{foo.baz}"
>>
>> So my proposal is the following.
>>
>> ==============
>> If the parameter "expressions" in ELProcessor.getValue (or setValue,
>> setVariable) does not contain a #{ or ${, it is assumed to be brackedted
>> by a #{ and }.
>>
>> For backward compatibility, the automatic bracketing is not applied to
>> the methods in ExpressionFactory.
>> ==============
>>
>> This is just another easy-of-use aspect for stand-alone EL.
>>
>> WDYT?
>>
> 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.
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)?
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.
Kin-man
> Mark
>