Current() in XPath predicate

Hi Mitch,

I think I'm missing something but I think that nothing is broken and that
the only issue is that the expression current()/../filterfield in your
example above should be just changed to current()/filterfield. If you make
that change, everything should work because it will be resolved to:

/data/group1/filterfield

Why should a "../" be present there? We have used current()/somefield
successfully in one of our test forms and it works fine. And I think it
would also work great in your example. Wouldn't it? Or am I totally out of
context?

Meletis

ยทยทยท On Friday, November 20, 2015 at 5:35:16 PM UTC+2, Mitch wrote: > > Hi Meletis, > > That's not the issue -- > > The issue is that if you use a filter condition in the nodeset > specification of a field "myfield", within that nodeset specification > "current()/.." refers to the parent of the group enclosing the "myfield" > field. It does not refer to the group enclosing the "myfield" field. > > So if you have > > > > > > > > > > > > > > > a > 4 > fish > > > b > 14 > fish > > ... > > > > and if you have: > > > nodeset="instance('food')/root/fooditem[filtercriteria=current()/../filterfield]"> > > > > > > This will currently be broken. Because current()/../filterfield, > when evaluated within the itemset nodeset specification, is resolved to: > > /data/filterfield > > instead of > > /data/group1/filterfield > > > On Fri, Nov 20, 2015 at 1:58 AM, <mel...@surveycto.com > wrote: > >> Well, I think there is a fundamental issue here regarding current() >> syntax. Please, let me remind you how JR works with "current()": >> >> 1. The expression "current()" looks like a function but it is not treated >> like one; it is not handled by the XPathFuncExpr class, so, if you try to >> use it alone you will get an error that the "function" is not supported. In >> other words, you cannot use it alone in an expression in order to refer to >> the "current" field. >> >> 2. When an expression includes "current()", then it ALWAYS needs to be >> used in an XPath, actually, the expression needs to BE an XPath expression, >> so that it can be handled with the XPathPathExpr class. For that reason the >> expression NEEDS to contain at least one "/". >> >> 3. Taking 1 and 2 into consideration, the ONLY way to refer to the >> "current" field (named "somefield") is to use "current()/." or >> "current()/somefield". So, I looks like that the original implementation >> was "okay" in the sense that the "current()" should only be used in XPaths. >> >> If we wanted to have "current()" refer to the current field, I believe we >> should introduce a new function handler in XPathFuncExpr class. Please let >> me know if this would work: >> >> A. Whenever the "current()" expression is used inside an XPath, then the >> current code would be used as it is used right now (maintaining backwards >> compatibility), so that it will still be referring to the enclosing group, >> not the field itself. >> B. Whenever the "current()" expression is used inside a non-XPath, then >> the new code would be used (in XPathFuncExpr) and that would be evaluated >> in a way that the current field would be returned/referenced, NOT the >> enclosing group. >> >> That way, the following code could work, because it wouldn't throw the >> "unrecognized function" error: >> >> >> label >> >> .... >> .... >> >> >> >> What do you think about that approach? >> >> Meletis >> >> >> >> On Friday, November 13, 2015 at 11:38:15 PM UTC+2, Martijn van de Rijdt wrote: >>> >>> Hi, >>> >>> I'd like to ask for a clarification about the current() node in an XPath >>> predicate. It seems JR considers this to be the *parent* node of the >>> current question. (Thanks to Chris for sharing this.) >>> >>> E.g. in this question below, current() equates to /data/group and not to >>> /data/group/options. I would have expected it to be the latter. >>> >>> >>> >>> .... >>> >>> >>> >>> >>> >>> label >>> >>> >>> >>> .... >>> >>> .... >>> >>> >>> >>> >>> >>> >>> Is this by design? Or is it a bug? >>> >>> >>> We ran into this by realizing that the seemingly more intuitive predicate >>> [name = current()*/../../*crop] is not working. >>> >>> >>> See this form >>> >>> that illustrates the behaviour nicely. If current() is used in a >>> calculation (even if it makes no sense to do so) this extra step down is >>> not taken, but in a predicate it is. So it seems the behaviour is not >>> related to the current() function but to how predicates are handled in JR. >>> >>> >>> Thanks, >>> Martijn >>> >>> >>> -- >> >> > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com >