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
