I would like to comment on the idea of pluggable
expression languages.
There is a huge psychological benefit to this feature.
You cannot overestimate how emotional the issue of
syntax is for a lot of people. On several projects
through my career I had to face this exact problem and
choose an expression language. Every time it led to
bloody religeous wars. Everybody has an opinion!
Somebody thinks it should be modeled after Java
expressions, somebody proposes XPath or XQuery or
EJB-QL, VB, JavaScript, you name it. And whichever
syntax you choose, somebody will think that you
offended their most fundamental beliefs, like that
"==" should be used for comparison and not "=". Now,
if you as much as leave open the _possibility_ for the
users to choose a language, the whole issue just goes
away.
Of course, I am all for the standardization of the
default language. I don't think the idea of
specifying an alternative language globally is good,
it would reduce reusability of JSPs and custom tag
libraries.
The <jx:expressionLanguage> tag is a way to set the
language more locally, but it also has the same
problem of scope. It is a little too global, I cannot
really apply the choice of language to an individual
expression.
In my opinion, the right scope for the language choice
is an individual expression. For instance, JSPTL could
allow an optional language prefix for expressions,
e.g. "xpath:$session/employees[name='john']",
"ejb-ql:FROM Employees WHERE name = 'john'" etc.
Thanks,
- Dmitri Plotnikov
[EMAIL PROTECTED]
> Date: Sat, 8 Sep 2001 18:43:34 -0400 (EDT)
> From: Shawn Bayern <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: [JSPTL] JXPath as yet another
> expression language
>
> On Sat, 8 Sep 2001, Dmitri Plotnikov wrote:
>
> > Even with this simplistic implementation, I was
> able to use XPaths with all
> > JSPTL tags.
> >
> > Very exciting!
>
> Yes, XPath has come up in JSPTL Expert-Group
> discussions as a potential
> expression language to support in JSPTL. It's not
> universally accepted as
> the best choice for this purpose, but it's
> definitely one of the prominent
> candidates.
>
> > Question: if we were to add JXPath as yet another
> expression language
> > to JSPTL, where would the source code belong? I
> don't think we should
> > introduce dependencies between the JSPTL and
> JXPath projects. JXPath
> > is in commons; it should not depend on anything
> except commons itself
> > as commons is supposed to be the foundation for
> the whole project.
> > OTOH, JSPTL is becoming a standard, therefore it
> should be easily
> > separable from the rest of Jakarta. Or are these
> assumptions
> > incorrect?
>
> My take on this, unofficially, is that the JSPTL
> standard would specify a
> particular language, which might be a subset of or
> reference to XPath.
> The JSPTL reference implementation could then use
> JXPath if JXPath ends up
> being suitable as a full or partial implementation
> of the JSPTL
> specification's expression language.
>
> The only dependencies, in other words, will be at
> the reference-
> implementation level. To my understanding, this is
> fine assuming that the
> end result is convenient for end users and fully
> implements the standard.
>
> But there are folks more knowledgeable about JCP
> processes and who can
> speak more authoritatively on the matter. This is
> just my current,
> personal understanding.
>
> Shawn Bayern
> (JSPTL reference-implementation lead)
>
>
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com
