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.
> 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.)
Mark