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
>