JPath is in the commons-sandbox

[Dmitri Plotnikov <dm...@plotnix.com>]

JPath is in the commons-sandbox.  Check out the API docs at
http://www.plotnix.com/jpath/api/

What can we do with it?

Here's an idea.  What if all Struts tags that currently support the
name/property attributes, also supported an "xpath" attribute?  It would
basically play the same role as a name/property pair.

We could map xpath to the Struts environment like this: pageContext or
request/session/application stack could represent a pool of variables.  The
current form bean could perform the role of the context node in the xpath
sense.  So, we could do things like:

<bean:write xpath="$books[title = $title]/author"/>

<html:text xpath="people[$index]/firstName"/>

Tremendous power.

For now there is a minor concern about the speed of JPath.  The current
implementation is slower than BeanUtils.  However, it does not have to be
that way: we can build a faster implementation of JPath.  Specifically,
there are two things that we can do to optimize it.

1. We can build a version that interprets xpath directly on JavaBeans
without constructing an intermediate DOM tree (we are currently working on
such an implementation).

2. We can also cache (optimized) parse trees for xpaths.  For example, let's
say JPath is asked to interpret "firstName".  First, it performs a quick
lookup in a cache. Let's say it is not the first time this particular xpath
is used.  JPath finds the parse tree generated earlier and that parse tree
contains one object that basically says: "Just get property called
'firstName' from the current object". The implementation of that can be as
fast as BeanUtils.

What do you think?

- Dmitri Plotnikov
dmitri@plotnix.com