On 02/16/12 03:09, Mark Thomas wrote:
> On 15/02/2012 22:50, Kin-man Chung wrote:
>
>> Thanks for the feed back on EL 3.0.
>>
>> EL has currently another xml special character, namely,<. How is this
>> handled in facelets?
>>
>> Regardless, it seems prudent to pick another symbol for concatenation.
>> Consider the expression
>>
>> foo&
>>
>> which in EL means foo concatenate amp. Already I can see there may be
>> confusions. :-)
>>
>> What does other EGs think about this?
>>
> There is a lack of hard data in the original report. Before we consider
> changing this I'd like to see some harder evidence than "I imagine".
>
It is hard to get hard evidence when EL 3.0 is not released. To foresee
problems ahead of time is part of the design. I certainly do not want
to cause problems for facelet and xml users since they would be our
important users.
>
>> I recall the other symbols we considered:
>>
>> 1. ++
>> 2. #
>> 3. +=
>> 4. !
>>
> Of those, "+=" would be my preference. I'd also like to throw "+" into
> the ring.
>
>
I'm OK with +=, if only because it is least likely to be used elsewhere.
I'm also OK with '+', although that'd break backward compatibility. If
we use it, it should work like that in JDK, i.e. it is a concatenation
if and only if one of the operands is a String. This is probably the
most "natural" for users and is worth the small incompatibility price.
>> In any case, we should also allow the string "concat" as an operator,
>> like "eq" or "lt" etc.
>>
> I agree a string form should also be supported. I'd suggest something
> shorter as all the other string forms are two or three characters.
> Possibilities:
> cc
>
This is a JSF reserved EL variable.
> cat
>
I vote for "cat".
> ct
> sc
>
> Mark
>
>
Kin-man
>> Kin-man
>>
>> On 02/15/12 08:31, Bauke Scholtz wrote:
>>
>>> Hi,
>>>
>>> I saw the proposal for the new EL 3.0 string concatenation operator&.
>>>
>>> The idea is at its own great. However, since a XML special character
>>> is been used, I wonder how it should be used in Facelets since that's
>>> a XML based view technology which needs to go through a XML parser
>>> first. I imagine that we'd need to escape the& as& everywhere.
>>> This isn't very developer friendly. I'd suggest a different operator
>>> symbol.
>>>
>>> Cheers, Bauke
>>>
>>>
>>
>