jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: jcr:deref in predicate with jcr:contains
Date Tue, 02 Jun 2009 12:00:19 GMT

On Mon, May 25, 2009 at 18:47, Dan Diephouse
<dan.diephouse@mulesource.com> wrote:
> I've made good progress on JCR-977. I now have a working implementation,
> although a bit rough around the edges.
> One of the use cases I wanted to support was using jcr:contains and
> jcr:deref in a predicate, but I'm not sure how the syntax should look. I
> came up with the following:
> //*[jcr:contains(people/jcr:deref(@worksfor, '*'),'ballmer')]
> (This builds off from the DerefTest. Given, this isn't an actual query that
> you're likely to do as it will return /testroot in the unit tests, which
> doesn't have a high semantic value for this case. But it is useful I swear
> :-))
> I suppose that syntax works, but it seems like it'd be useful to be able to
> drill down to further nodes. e.g.
> //*[people/jcr:deref(@worksfor, '*')/jcr:contains(.,'ballmer')/foo/@bar]
> This syntax doesn't make sense as jcr:contains isn't really a path location.

right, the return type of jcr:contains() is boolean and not a node set.

> What I really need is support for predicates in predicates! Does XPath
> account for any of these types of scenarios?

well, XPath in general would allow predicates in predicates, but
jackrabbit does not support it. e.g.

//*[people/jcr:deref(@worksfor, '*')[jcr:contains(.,'ballmer')]/foo/@bar]

is valid XPath syntax, but would require quite some enhancements to
the abstract query tree in jackrabbit.

> Or would the XPath way be more
> like:
> //*[jcr:contains(people/jcr:deref(@worksfor, '*'),'ballmer') and
> people/jcr:deref(@worksfor, '*')/foo/@bar]

that's probably easier to support with the current jackrabbit implementation.


> Cheers,
> Dan
> --
> Dan Diephouse
> http://mulesource.com | http://netzooid.com/blog

View raw message