On 08/22/11 03:20, Ramesh wrote:
>
>
> 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.)
I agree that with the addition of concatenation operator, composite
expressions can indeed be deprecated.
However, we don't need to. We can still allow composite expressions in
ExpressionFactory.createValueExpression etc, to be backward compatible,
but allow only ${...} in ELProcessor.getValeue etc, so that brackets are
not necessary. Composite expressions makes sense when EL is used as a
templating language, and is useful in a JSP page, whereas as a
stand-alone tool, the brackets seem unnecessary and ugly.
> But, the expressions inside the composite expressions can still have
> brackets for backwards compatibility.
>
I know my original proposal is to make #{ and } optional, but then I've
came to the conclusion that it would be simpler to just disallow
composite expressions with the new API. It is less confusing and have
better performance (no need to test if #{ } is present). BTW, there is
no backwards compatibility problem because the API is new. :-)
I know that we have to make this very clear in the spec, to avoid any
confusion.
Kin-man
Kin-man
> Ramesh
>> Mark
>>