JXPath comes with a light-weight implementation of DOM
that bridges between DOM and JavaBeans APIs. It
applies the Xalan XPath interpreter to that DOM tree.
This approach works. However it suffers from the same
performance issues as XSLT: the XPath interpreter
scans node lists when it is looking for stuff, so if
you have large node lists (in the case of JaveBeans:
collections or arrays), and you pay the price for the
convenience.
I did everything I could to make JXPath run fast
within the constraints of the chosen approach: I am
allocating as few objects as possible and accessing as
few JavaBean properties as possible. However, if we
wanted it to be _really_ fast, we would have to
reimplement the XPath interpreter to use JavaBeans
APIs directly. Another (though unrealistic) approach
would be to change the existing Xalan XPath
interpreter to use some form of delegation for data
access. For example instead of calling:
node.getFirstChild(), it might call
delegate.getFirstChild(node). The APIs of the delegate
could be designed in such a way that they can be
optimized for alternative kinds of data structures,
like delegate.getChildrenWithKey(node, key).
I know, I know... I am dreaming...
On Wed, 2 May 2001, Craig R. McClanahan wrote:
>On Wed, 2 May 2001, James Strachan wrote:
>
>> 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}
>>
>
>I'd like to explore adding Map-reference type syntax
to beanutils as well.
>
>> 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?
>>
>
>I think that makes a lot of sense. In the absence of
a standard yet, I
>don't see a problem with having more than one
alternative to experiment
>with, either.
>
>> 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.
>>
>
>Another STRUTS-DEV mailing list subscriber, Dmitri
Polotnikov
><[EMAIL PROTECTED]> has also proposed this idea (and
some code ;-) for
>Struts. I'd like to look at it with the eye towards
having an XPath-type
>language available for use as well. Having the basic
path-processing
>logic in Commons, and Struts-specific tags that use
it in Struts, seems
>like a good way to go.
>
>His proposed code is at
> http:>www.plotnix.com/jxpath
>
>> James
>>
>
>Craig
Dmitri Plotnikov
[EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
