Just a thought about the "bean expression languages".

The BeanUtils (and Struts) uses a bean langauge for evaluating properties

    customer.address
    equates to "getCustomer().getAddress()".

    customer.address[2].street
    equates to getCustomer().getAddress(2).getStreet()

Though I don't think it currently supports Maps nor look ups of variables
yet though it does support indexed properties. AFAIK the lookup of bean
variables is done by a seperate mechanism.

Morgan's foundation JSP tag library uses a bean expression language which is
similar but has support for Maps and arrays too though am not sure if it
supports indexed properties. Map syntax is {key} I think. For example:-

    user.addresses[1]{last}

In the JSR 052, (the standard JSP tag library spec) there is a need for a
bean expression language, which may also include logical operators too one
day.

Now I doubt we'll get convergence on a single bean expression language any
time soon but would it be appropriate to at least think about what such a
superset language might be that could meet everyones needs? (I understand it
could take a long time to ever standardise across all relevant Jakarta
projects, even  if we did get agreement day).
The Jakarta-Commons project would seem a good place to try develop such a
thing if ever we could get some form of agreement?

My own take on what such a language would look like is hugely tainted by
XPath (its a lovely language ;-)
So I'm considering JPath which has a near identical similar core syntax to
XPath and could fit the following needs quite easily

    * traverse a 'tree' of beans, bean properties, Maps, Collections and
arrays
    * has syntax for looking up variables
    * has support for boolean predicates and filters allowing collections &
arrays to be filtered and navigated
    * does not require '.' to be escaped in the use of variable names. (dots
are quite common for attribute names in JSP et al)
    * can be extended with functions if necessary

So to find the name property of a "foo" bean we could do

    $foo/name

which is equivalent to foo.getName()

To lookup a Properties (Map) object called "foo.bar" and find the "key"
value we could XPaths 'attribute' syntax

    $foo.bar/@key

Which is equivalent to foobar.get( "key" );

Then the [i] can be used to find a specific indexed array or collection
item.

    $customer/address[2]

which is equivalent to customer.getAddress(2)

The syntax can support the concept of a 'current context' so a relative path
expression could be

    address[2]

which is equivalent to context.getAddress(2)

XPath also supports filters and boolean expressions. So we could filter the
results returned via things like

    customers[location='US']/name

would select the names of the customers that are located in the US.


I'm getting close to being maxed out until after JavaOne but would something
like this gain much interest to jakarta-commons? It is quite taglibs /
struts specific I'd imagine.

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Reply via email to