Is there any progress on supporting cascading selects in repeating groups.
I have a form that requires this functionality and cannot be easily
remodelled.
Thank you so much for the quick response and for the detailed
explanation. Very much appreciated. Will try to redo our survey so we won't
have to use cascading select inside repeats.
Thanks again!
On Sat, Nov 3, 2012 at 12:53 AM, Mitch S mitche...@gmail.com wrote:
Yes, I believe this will run into the same issues as I had stated in the
earlier e-mail.
The second itemset restriction needs to reference the present value of
Province for that repeat element.
Unfortunately, /new_form3/A03/Province will return a set of values
beginning with the 2nd filled-out repeat group (because it matches and
returns all the Province matches in the form -- you need to restrict this
to the value in the current repeat group.
If things were working, you could do
...[@value=/new_form3/A03/MunCity[self::node()=.]/../Provice]...
But that is broken, per the earlier e-mail.
Right now, the only solution is to not do cascading selects within
repeat groups.
Mitch
On Fri, Nov 2, 2012 at 8:42 AM, Vinia Marciano viniam...@gmail.com wrote:
Hi Mitch!
Thanks for your reply. Howvever, this one's really quite complicated for
me. 
But I really appreciate your assistance. I am sending a sample of
the xml file I'm working on to better explain my problem. It's when adding
a second record in a repeating group with cascading select where I get the
error.
Attaching a copy of the xml.
Thanks.
On Wed, Sep 5, 2012 at 1:22 AM, Mitch S mitche...@gmail.com wrote:
It is actually in a private e-mail thread. Synopsis:
I have created a form, attached, that uses a data instance('choices') to
present 3 cascading select lists.
It is complicated by repeat groups. The last select needs to filter
the selection itemset by the value of its enclosing repeat group.
Note that the XPath expression I've used in the innermost question may
be overly complex. I am not an XPath expert and went through a half-dozen
expressions before coming up with this one.
PROBLEM: I believe the XPathNodeset and/or TreeReference in an XPath
expression are being prematurely resolved to an IAnswerData value.
If I write:
/form/path/element[self::node()=.]
I expect that 'self::node()' would resolve to an XPath node
(TreeReference), and '.'
would resolve to an XPath node (TreeReference), and that the '=' would
test for
equality of the two underlying FormIndex structures. I.e., it wouldn't
test for data value equality, but for a matching element in the DOM. At
it is, these appear to resolve down to their values(??) and those are
compared.
I think:
/form/path/element[self::text()=.]
would
test for equality between the IAnswerData in the element and the
IAnswerData of the current node within the form (granted, you wouldn't
write it this way, but I wanted a parallel construction [NOTE: ::text()
is not supported by the JR parser]).
Mitch
On Fri, Aug 31, 2012 at 8:46 PM, viniam...@gmail.com wrote:
Thank you for your response. However, I can't seem to find the thread
that provides the fix or solution. What key words should i use? I tried the
following keywords but didn't find the right thread: cascading nested group
error "type mismatch nodeset has more than one one".
How do I get to the right post?
Many thanks.
Vinia
On Wednesday, August 22, 2012 5:50:29 PM UTC+8, ニコノコ wrote:
I think it's been fixed. Please check the issues recently fixed on the
ODK code page.
On Wednesday, August 22, 2012, wrote:
Hi.
Any updates on this? I am also having the same problem with repeating
questions where I have cascading select within the group. We have questions
on Migration where each household member (repeating question) is asked
about his/her previous residence (cascading select: province => town). No
problem with entering the data for the first member of the household.
However, when a group is added, meaning another household member is a added
to the repeating group, the cascading select returns the error: 'type
mismatch nodeset has more than one node' .... 'cannot convert to value.'
Many thanks!
Vinia
On Thursday, July 19, 2012 12:09:44 PM UTC+8, ニコノコ wrote:
Thanks Nathan. So far, this theory 
only responds with this error:
XPath evaluation: unsupported construct [predicates]
I've asked at the ODK developers mailing list perhaps someone will
throw me a bone there.
Will update this thread if I find anything new.
On Wednesday, July 18, 2012, Nathan wrote:
I think you will need to use an xpath expression for that. You can
find some examples of them here:
http://www.w3schools.com/xpath/xpath_examples.asp
In theory something like ../repeat_group_name/*[n] should work,
however I'm not not sure if javarosa supports the * or selection by index
syntax, so it might not work.
Best of luck,
-Nathan
--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en