Hi, On Mon, May 25, 2009 at 18:47, Dan Diephouse <[email protected]> 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. regards marcel > Cheers, > Dan > -- > Dan Diephouse > http://mulesource.com | http://netzooid.com/blog >
