Jacques, Did you download that PDF file I mentioned previously? Also, there is a UEL tutorial:
http://java.sun.com/javaee/5/docs/tutorial/backup/doc/JSPIntro7.html -Adrian --- On Fri, 12/19/08, Jacques Le Roux <[email protected]> wrote: > 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 > > > >
