From: Jacques Le Roux <[email protected]>
Subject: Re: Discussion: Unified Expression Language Functions
To: [email protected]
Date: Friday, December 19, 2008, 9:27 AM
From: "Adrian Crum" <[email protected]>
> Adam Heath wrote:
>> David E Jones wrote:
>>> This may be a novel idea... but you could
always test them and see if
>>> they work or not... ;)
>>
>> How about we keep the current custom parser, but
then add uel as a
>> prefix, like ${bsh:} is, then issue warnings for
strings that don't
>> match a prefix, giving the line number/file of the
string.
>>
>> I think it'd be better to not have a default
language there, and always
>> explicitly request a particular language for
interpetting.
>>
>> Of course, there's one other major problem,
finding the end of the
>> token. Take for instance, the following String:
>>
>> toProcess =
"foo${bsh:\"abc\"+123+\"}\"}";
>>
>> Finding the matching {} there is difficult, if you
can't have a unified
>> parser for the multiple languages.
>>
>> ps: You could say that fixing the above could be
done by escaping the
>> internal '}'. But then you'd have
java-source-level escaping,
>> StringExpander-level escaping, chosen language
escaping, etc, all
>> conflicting/overlapping with each other.
>
> The home-grown parser is very limited. In the original
FlexibleMapAccessor code, it just scanned the expression for
a period and assumed any period found was a Map element
delimiter. Problem is, there could be periods anywhere in
the expression that aren't Map element delimiters.
>
> My preference is to replace the home-grown parser with
the JUEL parser - because it is far more sophisticated and
has been thoroughly tested.
>
> I also prefer to have UEL as the default language for
${} expressions - because it is well known, well documented,
and very powerful.
Maybe a bit enthusiast and not very well documented at this
stage, but my feeling is +1
Jacques
> -Adrian
>
>
