I have ran into the cascading select issue with repeat groups. I have tried
to build a cascading select to parse down the selection list and it works
quite well.........until the second iteration of the repeat is
entered.......everything is fine cascade select works okay but it still
selects the filter for the first iteration even if a different parameter
is selected.....
example
iteration(1) AS_CLASS(1)=Shop cascade_select options for Shop
are presented.........
iteration(2) AS_CLASS(2)=landscape cascade_select options for Shop are
presented.......other than the ones expected from landscape
my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS},
${group_Asset}, position(..))
I really need this to work unless someone else has another
option.......leaving a 1000 option scroll list is not an option for me.
I don't mind doing some work to make this right but I do not have a clue
what to look for............relational position is what looks to be a miss
in this. if I could place a position marker someplace and reference it in
the function to select the current iteration AS_CLASS then it will work.
select_one class AS_CLASS Asset Group
select_one eq_type ASSETTYPE Asset Type Code
See the list for issues around repeat groups. You likely need to move away
from the ${} syntax and use relative path (../group_asset) naming within a
repeat group.
This is a shortcoming of the code emitted by XLSForm.
Mitch
···
On Sat, Feb 1, 2014 at 10:59 AM, John Harper wrote:
I have ran into the cascading select issue with repeat groups. I have
tried to build a cascading select to parse down the selection list and it
works quite well.........until the second iteration of the repeat is
entered.......everything is fine cascade select works okay but it still
selects the filter for the first iteration even if a different parameter
is selected.....
example
iteration(1) AS_CLASS(1)=Shop cascade_select options for Shop
are presented.........
iteration(2) AS_CLASS(2)=landscape cascade_select options for Shop are
presented.......other than the ones expected from landscape
my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS},
${group_Asset}, position(..))
I really need this to work unless someone else has another
option.......leaving a 1000 option scroll list is not an option for me.
I don't mind doing some work to make this right but I do not have a clue
what to look for............relational position is what looks to be a miss
in this. if I could place a position marker someplace and reference it in
the function to select the current iteration AS_CLASS then it will work.
select_one class AS_CLASS Asset Group
select_one eq_type ASSETTYPE Asset Type Code
not an issue if it works.......any docs on relative path syntax?........I
would be using the filter column as [path][field]position(..) sound about
right to you..
···
On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
>
> See the list for issues around repeat groups. You likely need to move away
> from the ${} syntax and use relative path (../group_asset) naming within a
> repeat group.
>
> This is a shortcoming of the code emitted by XLSForm.
>
> Mitch
>
>
>
> On Sat, Feb 1, 2014 at 10:59 AM, John Harper <jharp...@gmail.com wrote:
>
>> I have ran into the cascading select issue with repeat groups. I have
>> tried to build a cascading select to parse down the selection list and it
>> works quite well.........until the second iteration of the repeat is
>> entered.......everything is fine cascade select works okay but it still
>> selects the filter for the first iteration even if a different parameter
>> is selected.....
>>
>>
>> example
>>
>> iteration(1) AS_CLASS(1)=Shop cascade_select options for Shop
>> are presented.........
>>
>> iteration(2) AS_CLASS(2)=landscape cascade_select options for Shop
>> are presented.......other than the ones expected from landscape
>>
>> my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS},
>> ${group_Asset}, position(..))
>>
>> I really need this to work unless someone else has another
>> option.......leaving a 1000 option scroll list is not an option for me.
>>
>> I don't mind doing some work to make this right but I do not have a clue
>> what to look for............relational position is what looks to be a miss
>> in this. if I could place a position marker someplace and reference it in
>> the function to select the current iteration AS_CLASS then it will work.
>>
>>
>> select_one class AS_CLASS Asset Group
>>
>>
>>
>>
>>
>> select_one eq_type ASSETTYPE Asset Type Code
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> --
>> Post: opend...@googlegroups.com
>> Unsubscribe: opendatakit...@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ODK Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to opendatakit...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> Mitch Sundt
> Software Engineer
> University of Washington
> mitche...@gmail.com
>
This has been filed as an issue at https://code.google.com/p/opendatakit/issues/detail?id=886. There was a
very long email discussion that followed the creation of that issue, and
unfortunately I'm not aware of any XPath syntax that actually works. If you
find that using a relative reference does actually work, please post a
comment to https://code.google.com/p/opendatakit/issues/detail?id=886.
Maybe there is a patch to XLSForm that we could make, to facilitate these
filtered choice lists within repeat groups. As things stand, it's a major
issue.
Best,
Chris
···
On Tue, Feb 4, 2014 at 9:33 AM, John Harper wrote:
Thanks Mitch.......I will give it a go.
not an issue if it works.......any docs on relative path syntax?........I
would be using the filter column as [path][field]position(..) sound about
right to you..
On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
See the list for issues around repeat groups. You likely need to move
away from the ${} syntax and use relative path (../group_asset) naming
within a repeat group.
This is a shortcoming of the code emitted by XLSForm.
I have ran into the cascading select issue with repeat groups. I have
tried to build a cascading select to parse down the selection list and it
works quite well.........until the second iteration of the repeat is
entered.......everything is fine cascade select works okay but it still
selects the filter for the first iteration even if a different parameter
is selected.....
example
iteration(1) AS_CLASS(1)=Shop cascade_select options for Shop
are presented.........
iteration(2) AS_CLASS(2)=landscape cascade_select options for Shop
are presented.......other than the ones expected from landscape
my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS},
${group_Asset}, position(..))
I really need this to work unless someone else has another
option.......leaving a 1000 option scroll list is not an option for me.
I don't mind doing some work to make this right but I do not have a clue
what to look for............relational position is what looks to be a miss
in this. if I could place a position marker someplace and reference it in
the function to select the current iteration AS_CLASS then it will work.
select_one class AS_CLASS Asset Group
select_one eq_type ASSETTYPE Asset Type Code
You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit...@googlegroups.com.
Chris this is absolutely infuriating .......................
using the index-repeat function I can set the filter-select column within
the group-repeat to the correct value of the cascade-select value.....I
switched it back to a regular select and placed a calculated field in
between just to see if the value was indeed correct.........it is correct
for each iteration just no love. even though the value seems to be passed
to the select-filter column the first value is the only one getting
selected............not sure what is going on.......
this is my select-filter syntax......works perfect on the first try........
if I put this into a calculate field I get the correct value every
time...........it just will not apparently pass the value to the
select-filter column..............
I will attach an example of the file..........need to pair it down a bit.
···
On Tuesday, February 4, 2014 7:41:27 AM UTC-7, Christopher Robert wrote:
>
> John,
>
> This has been filed as an issue at
> https://code.google.com/p/opendatakit/issues/detail?id=886. There was a
> very long email discussion that followed the creation of that issue, and
> unfortunately I'm not aware of any XPath syntax that actually works. If you
> find that using a relative reference does actually work, please post a
> comment to https://code.google.com/p/opendatakit/issues/detail?id=886.
> Maybe there is a patch to XLSForm that we could make, to facilitate these
> filtered choice lists within repeat groups. As things stand, it's a major
> issue.
>
> Best,
>
> Chris
>
>
>
> On Tue, Feb 4, 2014 at 9:33 AM, John Harper <jharp...@gmail.com wrote:
>
>> Thanks Mitch.......I will give it a go.
>>
>> not an issue if it works.......any docs on relative path syntax?........I
>> would be using the filter column as [path][field]position(..) sound about
>> right to you..
>>
>>
>> On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
>>
>>> See the list for issues around repeat groups. You likely need to move
>>> away from the ${} syntax and use relative path (../group_asset) naming
>>> within a repeat group.
>>>
>>> This is a shortcoming of the code emitted by XLSForm.
>>>
>>> Mitch
>>>
>>>
>>>
>>> On Sat, Feb 1, 2014 at 10:59 AM, John Harper wrote:
>>>
>>>> I have ran into the cascading select issue with repeat groups. I have
>>>> tried to build a cascading select to parse down the selection list and it
>>>> works quite well.........until the second iteration of the repeat is
>>>> entered.......everything is fine cascade select works okay but it still
>>>> selects the filter for the first iteration even if a different parameter
>>>> is selected.....
>>>>
>>>>
>>>> example
>>>>
>>>> iteration(1) AS_CLASS(1)=Shop cascade_select options for
>>>> Shop are presented.........
>>>>
>>>> iteration(2) AS_CLASS(2)=landscape cascade_select options for Shop
>>>> are presented.......other than the ones expected from landscape
>>>>
>>>> my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS},
>>>> ${group_Asset}, position(..))
>>>>
>>>> I really need this to work unless someone else has another
>>>> option.......leaving a 1000 option scroll list is not an option for me.
>>>>
>>>> I don't mind doing some work to make this right but I do not have a
>>>> clue what to look for............relational position is what looks to be a
>>>> miss in this. if I could place a position marker someplace and reference
>>>> it in the function to select the current iteration AS_CLASS then it will
>>>> work.
>>>>
>>>>
>>>> select_one class AS_CLASS Asset Group
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> select_one eq_type ASSETTYPE Asset Type Code
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Post: opend...@googlegroups.com
>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>>
>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ODK Community" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to opendatakit...@googlegroups.com.
>>>>
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ODK Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to opendatakit...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
I'm very sorry. We had the very same experience. The trouble is that the
context is just not quite right when it's evaluating the filter -- so it
always thinks that it's in the first iteration.
Mitch may be right that there's some kind of relative XPath reference that
will work in that context, but we couldn't find anything that worked when
we last struggled with it. The best fix for users would be to make it so
that absolute XPath references, of the style created by XLSForm, work the
same in this filter context as they do elsewhere -- but there is resistance
to that, because I guess that it's not the way the JavaRosa/XForm standard
was meant to work. But then I haven't seen any other fix or work-around
either.
SurveyCTO users have been working around this by using our "dynamic
search-and-select" feature, whereby multiple-choice options are pulled
dynamically from a pre-loaded .csv file. We're working with Nafundi and
University of Washington on a deal to open-source our pre-loading features,
so I hope that that work-around will become available to non-SurveyCTO
users in the relatively near future. Then I guess everybody can more easily
live without this fix.
Best,
Chris
···
On Wed, Feb 5, 2014 at 11:14 PM, John Harper wrote:
Chris this is absolutely infuriating .......................
using the index-repeat function I can set the filter-select column within
the group-repeat to the correct value of the cascade-select value.....I
switched it back to a regular select and placed a calculated field in
between just to see if the value was indeed correct.........it is correct
for each iteration just no love. even though the value seems to be passed
to the select-filter column the first value is the only one getting
selected............not sure what is going on.......
this is my select-filter syntax......works perfect on the first try........
if I put this into a calculate field I get the correct value every
time...........it just will not apparently pass the value to the
select-filter column..............
I will attach an example of the file..........need to pair it down a bit.
On Tuesday, February 4, 2014 7:41:27 AM UTC-7, Christopher Robert wrote:
John,
This has been filed as an issue at https://code.google.com/p/
opendatakit/issues/detail?id=886. There was a very long email discussion
that followed the creation of that issue, and unfortunately I'm not aware
of any XPath syntax that actually works. If you find that using a relative
reference does actually work, please post a comment to https://code.google.com/p/opendatakit/issues/detail?id=886. Maybe there
is a patch to XLSForm that we could make, to facilitate these filtered
choice lists within repeat groups. As things stand, it's a major issue.
not an issue if it works.......any docs on relative path
syntax?........I would be using the filter column as
[path][field]position(..) sound about right to you..
On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
See the list for issues around repeat groups. You likely need to move
away from the ${} syntax and use relative path (../group_asset) naming
within a repeat group.
This is a shortcoming of the code emitted by XLSForm.
I have ran into the cascading select issue with repeat groups. I have
tried to build a cascading select to parse down the selection list and it
works quite well.........until the second iteration of the repeat is
entered.......everything is fine cascade select works okay but it still
selects the filter for the first iteration even if a different parameter
is selected.....
example
iteration(1) AS_CLASS(1)=Shop cascade_select options for
Shop are presented.........
iteration(2) AS_CLASS(2)=landscape cascade_select options for
Shop are presented.......other than the ones expected from landscape
my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS},
${group_Asset}, position(..))
I really need this to work unless someone else has another
option.......leaving a 1000 option scroll list is not an option for me.
I don't mind doing some work to make this right but I do not have a
clue what to look for............relational position is what looks to be a
miss in this. if I could place a position marker someplace and reference
it in the function to select the current iteration AS_CLASS then it will
work.
select_one class AS_CLASS Asset Group
select_one eq_type ASSETTYPE Asset Type Code
You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit...@googlegroups.com.
Thanks for the comments Chris. I am hoping that this will come
soon............I am not famillar with the absolute XPath reference syntax
or I would try it as well. I will do some googling..........any ref on
this would be appreciated.
···
On Thu, Feb 6, 2014 at 4:41 AM, Christopher Robert wrote:
John,
I'm very sorry. We had the very same experience. The trouble is that the
context is just not quite right when it's evaluating the filter -- so it
always thinks that it's in the first iteration.
Mitch may be right that there's some kind of relative XPath reference that
will work in that context, but we couldn't find anything that worked when
we last struggled with it. The best fix for users would be to make it so
that absolute XPath references, of the style created by XLSForm, work the
same in this filter context as they do elsewhere -- but there is resistance
to that, because I guess that it's not the way the JavaRosa/XForm standard
was meant to work. But then I haven't seen any other fix or work-around
either.
SurveyCTO users have been working around this by using our "dynamic
search-and-select" feature, whereby multiple-choice options are pulled
dynamically from a pre-loaded .csv file. We're working with Nafundi and
University of Washington on a deal to open-source our pre-loading features,
so I hope that that work-around will become available to non-SurveyCTO
users in the relatively near future. Then I guess everybody can more easily
live without this fix.
Chris this is absolutely infuriating .......................
using the index-repeat function I can set the filter-select column within
the group-repeat to the correct value of the cascade-select value.....I
switched it back to a regular select and placed a calculated field in
between just to see if the value was indeed correct.........it is correct
for each iteration just no love. even though the value seems to be passed
to the select-filter column the first value is the only one getting
selected............not sure what is going on.......
this is my select-filter syntax......works perfect on the first
try........
if I put this into a calculate field I get the correct value every
time...........it just will not apparently pass the value to the
select-filter column..............
I will attach an example of the file..........need to pair it down a bit.
On Tuesday, February 4, 2014 7:41:27 AM UTC-7, Christopher Robert wrote:
John,
This has been filed as an issue at https://code.google.com/p/
opendatakit/issues/detail?id=886. There was a very long email
discussion that followed the creation of that issue, and unfortunately I'm
not aware of any XPath syntax that actually works. If you find that using a
relative reference does actually work, please post a comment to https://code.google.com/p/opendatakit/issues/detail?id=886. Maybe there
is a patch to XLSForm that we could make, to facilitate these filtered
choice lists within repeat groups. As things stand, it's a major issue.
not an issue if it works.......any docs on relative path
syntax?........I would be using the filter column as
[path][field]position(..) sound about right to you..
On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
See the list for issues around repeat groups. You likely need to move
away from the ${} syntax and use relative path (../group_asset) naming
within a repeat group.
This is a shortcoming of the code emitted by XLSForm.
I have ran into the cascading select issue with repeat groups. I have
tried to build a cascading select to parse down the selection list and it
works quite well.........until the second iteration of the repeat is
entered.......everything is fine cascade select works okay but it still
selects the filter for the first iteration even if a different parameter
is selected.....
example
iteration(1) AS_CLASS(1)=Shop cascade_select options for
Shop are presented.........
iteration(2) AS_CLASS(2)=landscape cascade_select options for
Shop are presented.......other than the ones expected from landscape
my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS},
${group_Asset}, position(..))
I really need this to work unless someone else has another
option.......leaving a 1000 option scroll list is not an option for me.
I don't mind doing some work to make this right but I do not have a
clue what to look for............relational position is what looks to be a
miss in this. if I could place a position marker someplace and reference
it in the function to select the current iteration AS_CLASS then it will
work.
select_one class AS_CLASS Asset Group
select_one eq_type ASSETTYPE Asset Type Code
You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to opendatakit...@googlegroups.com.
You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
If you have two fields, field1 and field2, inside the same repeat group,
then you generally want field2 to reference field1 with a relative path
like "../field1" rather than with an absolute path like
"/formid/groupname/field1". That's the big-picture issue here: XLSForm
always uses absolute references, and it relies on ODK/JavaRosa resolving
those references based on the current context -- which works basically
everywhere except here, with these cascading-select filters. The issue is
that some people don't think that it should be fixed, because the absolute
paths aren't the correct approach: relative paths are the correct approach.
But then, as far as I could tell, relative paths actually don't work either
-- but you can correct me if I'm wrong, if you're able to get them to work.
Best,
Chris
···
On Thu, Feb 6, 2014 at 7:54 AM, John Harper wrote:
Thanks for the comments Chris. I am hoping that this will come
soon............I am not famillar with the absolute XPath reference syntax
or I would try it as well. I will do some googling..........any ref on
this would be appreciated.
I'm very sorry. We had the very same experience. The trouble is that the
context is just not quite right when it's evaluating the filter -- so it
always thinks that it's in the first iteration.
Mitch may be right that there's some kind of relative XPath reference
that will work in that context, but we couldn't find anything that worked
when we last struggled with it. The best fix for users would be to make it
so that absolute XPath references, of the style created by XLSForm, work
the same in this filter context as they do elsewhere -- but there is
resistance to that, because I guess that it's not the way the
JavaRosa/XForm standard was meant to work. But then I haven't seen any
other fix or work-around either.
SurveyCTO users have been working around this by using our "dynamic
search-and-select" feature, whereby multiple-choice options are pulled
dynamically from a pre-loaded .csv file. We're working with Nafundi and
University of Washington on a deal to open-source our pre-loading features,
so I hope that that work-around will become available to non-SurveyCTO
users in the relatively near future. Then I guess everybody can more easily
live without this fix.
Chris this is absolutely infuriating .......................
using the index-repeat function I can set the filter-select column
within the group-repeat to the correct value of the cascade-select
value.....I switched it back to a regular select and placed a calculated
field in between just to see if the value was indeed correct.........it is
correct for each iteration just no love. even though the value seems to be
passed to the select-filter column the first value is the only one getting
selected............not sure what is going on.......
this is my select-filter syntax......works perfect on the first
try........
if I put this into a calculate field I get the correct value every
time...........it just will not apparently pass the value to the
select-filter column..............
I will attach an example of the file..........need to pair it down a
bit.
On Tuesday, February 4, 2014 7:41:27 AM UTC-7, Christopher Robert wrote:
John,
This has been filed as an issue at https://code.google.com/p/
opendatakit/issues/detail?id=886. There was a very long email
discussion that followed the creation of that issue, and unfortunately I'm
not aware of any XPath syntax that actually works. If you find that using a
relative reference does actually work, please post a comment to https://code.google.com/p/opendatakit/issues/detail?id=886. Maybe
there is a patch to XLSForm that we could make, to facilitate these
filtered choice lists within repeat groups. As things stand, it's a major
issue.
not an issue if it works.......any docs on relative path
syntax?........I would be using the filter column as
[path][field]position(..) sound about right to you..
On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
See the list for issues around repeat groups. You likely need to move
away from the ${} syntax and use relative path (../group_asset) naming
within a repeat group.
This is a shortcoming of the code emitted by XLSForm.
I have ran into the cascading select issue with repeat groups. I
have tried to build a cascading select to parse down the selection list and
it works quite well.........until the second iteration of the repeat is
entered.......everything is fine cascade select works okay but it still
selects the filter for the first iteration even if a different parameter
is selected.....
example
iteration(1) AS_CLASS(1)=Shop cascade_select options for
Shop are presented.........
iteration(2) AS_CLASS(2)=landscape cascade_select options for
Shop are presented.......other than the ones expected from landscape
my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS},
${group_Asset}, position(..))
I really need this to work unless someone else has another
option.......leaving a 1000 option scroll list is not an option for me.
I don't mind doing some work to make this right but I do not have a
clue what to look for............relational position is what looks to be a
miss in this. if I could place a position marker someplace and reference
it in the function to select the current iteration AS_CLASS then it will
work.
select_one class AS_CLASS Asset Group
select_one eq_type ASSETTYPE Asset Type Code
You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to opendatakit...@googlegroups.com.
You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit+unsubscribe@googlegroups.com.
(1) if XLSForm changes to use relative paths, this would fix most people's
issues with things breaking within repeat groups.
but,
(2) the larger problem is the expressiveness of XPath notation. While you
need relative paths to correctly reference values within repeat groups, if
you then use relative paths within the filter expresions of a cascading
select (external itemset), the relative value is interpreted relative to
that external dataset, not relative to your survey values.
i.e., you need absolute references when using cascading selects.
···
----
The end result is that changing (1) to fix repeat groups will introduce
failures in cascading selects (2) *all the time*.
So we are stuck in our current situation where we have usable cascading
selects but repeat groups are generally difficult to get right and using
cascading selects within them is very hard or impossible.
This is a prominent reason the ODK 2.0 tools have abandoned XForms and
XPath expressions, and turned to Javascript and HTML as the base
descriptive languages.
The tools shouldn't prevent people from doing what they want to do because
of a technology choice they don't generally care about.
If you have two fields, field1 and field2, inside the same repeat group,
then you generally want field2 to reference field1 with a relative path
like "../field1" rather than with an absolute path like
"/formid/groupname/field1". That's the big-picture issue here: XLSForm
always uses absolute references, and it relies on ODK/JavaRosa resolving
those references based on the current context -- which works basically
everywhere except here, with these cascading-select filters. The issue is
that some people don't think that it should be fixed, because the absolute
paths aren't the correct approach: relative paths are the correct approach.
But then, as far as I could tell, relative paths actually don't work either
-- but you can correct me if I'm wrong, if you're able to get them to work.
Thanks for the comments Chris. I am hoping that this will come
soon............I am not famillar with the absolute XPath reference syntax
or I would try it as well. I will do some googling..........any ref on
this would be appreciated.
I'm very sorry. We had the very same experience. The trouble is that the
context is just not quite right when it's evaluating the filter -- so it
always thinks that it's in the first iteration.
Mitch may be right that there's some kind of relative XPath reference
that will work in that context, but we couldn't find anything that worked
when we last struggled with it. The best fix for users would be to make it
so that absolute XPath references, of the style created by XLSForm, work
the same in this filter context as they do elsewhere -- but there is
resistance to that, because I guess that it's not the way the
JavaRosa/XForm standard was meant to work. But then I haven't seen any
other fix or work-around either.
SurveyCTO users have been working around this by using our "dynamic
search-and-select" feature, whereby multiple-choice options are pulled
dynamically from a pre-loaded .csv file. We're working with Nafundi and
University of Washington on a deal to open-source our pre-loading features,
so I hope that that work-around will become available to non-SurveyCTO
users in the relatively near future. Then I guess everybody can more easily
live without this fix.
Chris this is absolutely infuriating .......................
using the index-repeat function I can set the filter-select column
within the group-repeat to the correct value of the cascade-select
value.....I switched it back to a regular select and placed a calculated
field in between just to see if the value was indeed correct.........it is
correct for each iteration just no love. even though the value seems to be
passed to the select-filter column the first value is the only one getting
selected............not sure what is going on.......
this is my select-filter syntax......works perfect on the first
try........
if I put this into a calculate field I get the correct value every
time...........it just will not apparently pass the value to the
select-filter column..............
I will attach an example of the file..........need to pair it down a
bit.
On Tuesday, February 4, 2014 7:41:27 AM UTC-7, Christopher Robert wrote:
John,
This has been filed as an issue at https://code.google.com/p/
opendatakit/issues/detail?id=886. There was a very long email
discussion that followed the creation of that issue, and unfortunately I'm
not aware of any XPath syntax that actually works. If you find that using a
relative reference does actually work, please post a comment to https://code.google.com/p/opendatakit/issues/detail?id=886. Maybe
there is a patch to XLSForm that we could make, to facilitate these
filtered choice lists within repeat groups. As things stand, it's a major
issue.
not an issue if it works.......any docs on relative path
syntax?........I would be using the filter column as
[path][field]position(..) sound about right to you..
On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
See the list for issues around repeat groups. You likely need to
move away from the ${} syntax and use relative path (../group_asset) naming
within a repeat group.
This is a shortcoming of the code emitted by XLSForm.
I have ran into the cascading select issue with repeat groups. I
have tried to build a cascading select to parse down the selection list and
it works quite well.........until the second iteration of the repeat is
entered.......everything is fine cascade select works okay but it still
selects the filter for the first iteration even if a different parameter
is selected.....
example
iteration(1) AS_CLASS(1)=Shop cascade_select options for
Shop are presented.........
iteration(2) AS_CLASS(2)=landscape cascade_select options for
Shop are presented.......other than the ones expected from landscape
my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS},
${group_Asset}, position(..))
I really need this to work unless someone else has another
option.......leaving a 1000 option scroll list is not an option for me.
I don't mind doing some work to make this right but I do not have a
clue what to look for............relational position is what looks to be a
miss in this. if I could place a position marker someplace and reference
it in the function to select the current iteration AS_CLASS then it will
work.
select_one class AS_CLASS Asset Group
select_one eq_type ASSETTYPE Asset Type Code
You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to opendatakit...@googlegroups.com.
You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit+unsubscribe@googlegroups.com.
@mitch, good point. That's very unfortunate. I can now see that this would
be a blocker for (finally) introducing correct relative XPath syntax for
nodes inside repeats. I guess we'd need fuller XPath support to generate
the proper syntax for cascading filters inside repeats.
···
On Thursday, February 6, 2014 10:34:40 AM UTC-7, Mitch Sundt wrote:
>
> The bind:
>
> (1) if XLSForm changes to use relative paths, this would fix most people's
> issues with things breaking within repeat groups.
>
> but,
>
> (2) the larger problem is the expressiveness of XPath notation. While you
> need relative paths to correctly reference values within repeat groups, if
> you then use relative paths within the filter expresions of a cascading
> select (external itemset), the relative value is interpreted relative to
> that external dataset, not relative to your survey values.
>
> i.e., you need absolute references when using cascading selects.
>
> ----
> The end result is that changing (1) to fix repeat groups will introduce
> failures in cascading selects (2) *all the time*.
>
> So we are stuck in our current situation where we have usable cascading
> selects but repeat groups are generally difficult to get right and using
> cascading selects within them is very hard or impossible.
> ==========
>
> This is a prominent reason the ODK 2.0 tools have abandoned XForms and
> XPath expressions, and turned to Javascript and HTML as the base
> descriptive languages.
>
> The tools shouldn't prevent people from doing what they want to do because
> of a technology choice they don't generally care about.
>
> Mitch
>
>
>
>
> On Thu, Feb 6, 2014 at 5:18 AM, Christopher Robert <chrisl...@gmail.com wrote:
>
>> John,
>>
>> If you have two fields, field1 and field2, inside the same repeat group,
>> then you generally want field2 to reference field1 with a relative path
>> like "../field1" rather than with an absolute path like
>> "/formid/groupname/field1". That's the big-picture issue here: XLSForm
>> always uses absolute references, and it relies on ODK/JavaRosa resolving
>> those references based on the current context -- which works basically
>> everywhere except here, with these cascading-select filters. The issue is
>> that some people don't think that it should be fixed, because the absolute
>> paths aren't the correct approach: relative paths are the correct approach.
>> But then, as far as I could tell, relative paths actually don't work either
>> -- but you can correct me if I'm wrong, if you're able to get them to work.
>>
>> Best,
>>
>> Chris
>>
>>
>>
>>
>> On Thu, Feb 6, 2014 at 7:54 AM, John Harper <jharp...@gmail.com wrote:
>>
>>> Thanks for the comments Chris. I am hoping that this will come
>>> soon............I am not famillar with the absolute XPath reference syntax
>>> or I would try it as well. I will do some googling..........any ref on
>>> this would be appreciated.
>>>
>>>
>>> On Thu, Feb 6, 2014 at 4:41 AM, Christopher Robert <cro...@surveycto.com wrote:
>>>
>>>> John,
>>>>
>>>> I'm very sorry. We had the very same experience. The trouble is that
>>>> the context is just not quite right when it's evaluating the filter -- so
>>>> it always thinks that it's in the first iteration.
>>>>
>>>> Mitch may be right that there's some kind of relative XPath reference
>>>> that will work in that context, but we couldn't find anything that worked
>>>> when we last struggled with it. The best fix for users would be to make it
>>>> so that absolute XPath references, of the style created by XLSForm, work
>>>> the same in this filter context as they do elsewhere -- but there is
>>>> resistance to that, because I guess that it's not the way the
>>>> JavaRosa/XForm standard was meant to work. But then I haven't seen any
>>>> other fix or work-around either.
>>>>
>>>> SurveyCTO users have been working around this by using our "dynamic
>>>> search-and-select" feature, whereby multiple-choice options are pulled
>>>> dynamically from a pre-loaded .csv file. We're working with Nafundi and
>>>> University of Washington on a deal to open-source our pre-loading features,
>>>> so I hope that that work-around will become available to non-SurveyCTO
>>>> users in the relatively near future. Then I guess everybody can more easily
>>>> live without this fix.
>>>>
>>>> Best,
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> On Wed, Feb 5, 2014 at 11:14 PM, John Harper <jharp...@gmail.com wrote:
>>>>
>>>>> Chris this is absolutely infuriating .......................
>>>>>
>>>>> using the index-repeat function I can set the filter-select column
>>>>> within the group-repeat to the correct value of the cascade-select
>>>>> value.....I switched it back to a regular select and placed a calculated
>>>>> field in between just to see if the value was indeed correct.........it is
>>>>> correct for each iteration just no love. even though the value seems to be
>>>>> passed to the select-filter column the first value is the only one getting
>>>>> selected............not sure what is going on.......
>>>>>
>>>>> this is my select-filter syntax......works perfect on the first
>>>>> try........
>>>>>
>>>>> class1=indexed-repeat(${AS_CLASS}, ${group_Asset},position(..))
>>>>>
>>>>> if I put this into a calculate field I get the correct value every
>>>>> time...........it just will not apparently pass the value to the
>>>>> select-filter column..............
>>>>>
>>>>>
>>>>> I will attach an example of the file..........need to pair it down a
>>>>> bit.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, February 4, 2014 7:41:27 AM UTC-7, Christopher Robert wrote:
>>>>>
>>>>>> John,
>>>>>>
>>>>>> This has been filed as an issue at https://code.google.com/p/
>>>>>> opendatakit/issues/detail?id=886. There was a very long email
>>>>>> discussion that followed the creation of that issue, and unfortunately I'm
>>>>>> not aware of any XPath syntax that actually works. If you find that using a
>>>>>> relative reference does actually work, please post a comment to
>>>>>> https://code.google.com/p/opendatakit/issues/detail?id=886. Maybe
>>>>>> there is a patch to XLSForm that we could make, to facilitate these
>>>>>> filtered choice lists within repeat groups. As things stand, it's a major
>>>>>> issue.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 4, 2014 at 9:33 AM, John Harper wrote:
>>>>>>
>>>>>>> Thanks Mitch.......I will give it a go.
>>>>>>>
>>>>>>> not an issue if it works.......any docs on relative path
>>>>>>> syntax?........I would be using the filter column as
>>>>>>> [path][field]position(..) sound about right to you..
>>>>>>>
>>>>>>>
>>>>>>> On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
>>>>>>>
>>>>>>>> See the list for issues around repeat groups. You likely need to
>>>>>>>> move away from the ${} syntax and use relative path (../group_asset) naming
>>>>>>>> within a repeat group.
>>>>>>>>
>>>>>>>> This is a shortcoming of the code emitted by XLSForm.
>>>>>>>>
>>>>>>>> Mitch
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Feb 1, 2014 at 10:59 AM, John Harper wrote:
>>>>>>>>
>>>>>>>>> I have ran into the cascading select issue with repeat groups. I
>>>>>>>>> have tried to build a cascading select to parse down the selection list and
>>>>>>>>> it works quite well.........until the second iteration of the repeat is
>>>>>>>>> entered.......everything is fine cascade select works okay but it still
>>>>>>>>> selects the filter for the first iteration even if a different parameter
>>>>>>>>> is selected.....
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> example
>>>>>>>>>
>>>>>>>>> iteration(1) AS_CLASS(1)=Shop cascade_select options
>>>>>>>>> for Shop are presented.........
>>>>>>>>>
>>>>>>>>> iteration(2) AS_CLASS(2)=landscape cascade_select options for
>>>>>>>>> Shop are presented.......other than the ones expected from landscape
>>>>>>>>>
>>>>>>>>> my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS},
>>>>>>>>> ${group_Asset}, position(..))
>>>>>>>>>
>>>>>>>>> I really need this to work unless someone else has another
>>>>>>>>> option.......leaving a 1000 option scroll list is not an option for me.
>>>>>>>>>
>>>>>>>>> I don't mind doing some work to make this right but I do not have
>>>>>>>>> a clue what to look for............relational position is what looks to be
>>>>>>>>> a miss in this. if I could place a position marker someplace and reference
>>>>>>>>> it in the function to select the current iteration AS_CLASS then it will
>>>>>>>>> work.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> select_one class AS_CLASS Asset Group
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> select_one eq_type ASSETTYPE Asset Type Code
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> --
>>>>>>>>> Post: opend...@googlegroups.com
>>>>>>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>>>>>>>
>>>>>>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>> Groups "ODK Community" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> send an email to opendatakit...@googlegroups.com.
>>>>>>>>>
>>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>>>>
>>>>>>> ---
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "ODK Community" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to opendatakit...@googlegroups.com.
>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>
>>>>>>
>>>>>> --
>>>>> --
>>>>> Post: opend...@googlegroups.com
>>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>>
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "ODK Community" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to opendatakit...@googlegroups.com .
>>>>>
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>
>>>> --
>>>> --
>>>> Post: opend...@googlegroups.com
>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>
>>>> ---
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "ODK Community" group.
>>>> To unsubscribe from this topic, visit
>>>> https://groups.google.com/d/topic/opendatakit/Ehu0lscXN8E/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> opendatakit...@googlegroups.com .
>>>>
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>
>>> --
>>> --
>>> Post: opend...@googlegroups.com
>>> Unsubscribe: opendatakit...@googlegroups.com
>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ODK Community" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to opendatakit...@googlegroups.com .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>> --
>> --
>> Post: opend...@googlegroups.com
>> Unsubscribe: opendatakit...@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ODK Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to opendatakit...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> Mitch Sundt
> Software Engineer
> University of Washington
> mitche...@gmail.com
>
@mitch, good point. That's very unfortunate. I can now see that this would be a blocker for (finally) introducing correct relative XPath syntax for nodes inside repeats. I guess we'd need fuller XPath support to generate the proper syntax for cascading filters inside repeats.
On Thursday, February 6, 2014 10:34:40 AM UTC-7, Mitch Sundt wrote:
The bind:
(1) if XLSForm changes to use relative paths, this would fix most people's issues with things breaking within repeat groups.
but,
(2) the larger problem is the expressiveness of XPath notation. While you need relative paths to correctly reference values within repeat groups, if you then use relative paths within the filter expresions of a cascading select (external itemset), the relative value is interpreted relative to that external dataset, not relative to your survey values.
i.e., you need absolute references when using cascading selects.
The end result is that changing (1) to fix repeat groups will introduce failures in cascading selects (2) all the time.
So we are stuck in our current situation where we have usable cascading selects but repeat groups are generally difficult to get right and using cascading selects within them is very hard or impossible.
This is a prominent reason the ODK 2.0 tools have abandoned XForms and XPath expressions, and turned to Javascript and HTML as the base descriptive languages.
The tools shouldn't prevent people from doing what they want to do because of a technology choice they don't generally care about.
Mitch
On Thu, Feb 6, 2014 at 5:18 AM, Christopher Robert chrisl...@gmail.com wrote:
John,
If you have two fields, field1 and field2, inside the same repeat group, then you generally want field2 to reference field1 with a relative path like "../field1" rather than with an absolute path like "/formid/groupname/field1". That's the big-picture issue here: XLSForm always uses absolute references, and it relies on ODK/JavaRosa resolving those references based on the current context -- which works basically everywhere except here, with these cascading-select filters. The issue is that some people don't think that it should be fixed, because the absolute paths aren't the correct approach: relative paths are the correct approach. But then, as far as I could tell, relative paths actually don't work either -- but you can correct me if I'm wrong, if you're able to get them to work.
Thanks for the comments Chris. I am hoping that this will come soon............I am not famillar with the absolute XPath reference syntax or I would try it as well. I will do some googling..........any ref on this would be appreciated.
I'm very sorry. We had the very same experience. The trouble is that the context is just not quite right when it's evaluating the filter -- so it always thinks that it's in the first iteration.
Mitch may be right that there's some kind of relative XPath reference that will work in that context, but we couldn't find anything that worked when we last struggled with it. The best fix for users would be to make it so that absolute XPath references, of the style created by XLSForm, work the same in this filter context as they do elsewhere -- but there is resistance to that, because I guess that it's not the way the JavaRosa/XForm standard was meant to work. But then I haven't seen any other fix or work-around either.
SurveyCTO users have been working around this by using our "dynamic search-and-select" feature, whereby multiple-choice options are pulled dynamically from a pre-loaded .csv file. We're working with Nafundi and University of Washington on a deal to open-source our pre-loading features, so I hope that that work-around will become available to non-SurveyCTO users in the relatively near future. Then I guess everybody can more easily live without this fix.
Chris this is absolutely infuriating .......................
using the index-repeat function I can set the filter-select column within the group-repeat to the correct value of the cascade-select value.....I switched it back to a regular select and placed a calculated field in between just to see if the value was indeed correct.........it is correct for each iteration just no love. even though the value seems to be passed to the select-filter column the first value is the only one getting selected............not sure what is going on.......
this is my select-filter syntax......works perfect on the first try........
if I put this into a calculate field I get the correct value every time...........it just will not apparently pass the value to the select-filter column..............
I will attach an example of the file..........need to pair it down a bit.
On Tuesday, February 4, 2014 7:41:27 AM UTC-7, Christopher Robert wrote:
John,
This has been filed as an issue at https://code.google.com/p/opendatakit/issues/detail?id=886. There was a very long email discussion that followed the creation of that issue, and unfortunately I'm not aware of any XPath syntax that actually works. If you find that using a relative reference does actually work, please post a comment to https://code.google.com/p/opendatakit/issues/detail?id=886. Maybe there is a patch to XLSForm that we could make, to facilitate these filtered choice lists within repeat groups. As things stand, it's a major issue.
not an issue if it works.......any docs on relative path syntax?........I would be using the filter column as [path][field]position(..) sound about right to you..
On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
See the list for issues around repeat groups. You likely need to move away from the ${} syntax and use relative path (../group_asset) naming within a repeat group.
This is a shortcoming of the code emitted by XLSForm.
I have ran into the cascading select issue with repeat groups. I have tried to build a cascading select to parse down the selection list and it works quite well.........until the second iteration of the repeat is entered.......everything is fine cascade select works okay but it still selects the filter for the first iteration even if a different parameter is selected.....
example
iteration(1) AS_CLASS(1)=Shop cascade_select options for Shop are presented.........
iteration(2) AS_CLASS(2)=landscape cascade_select options for Shop are presented.......other than the ones expected from landscape
my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS}, ${group_Asset}, position(..))
I really need this to work unless someone else has another option.......leaving a 1000 option scroll list is not an option for me.
I don't mind doing some work to make this right but I do not have a clue what to look for............relational position is what looks to be a miss in this. if I could place a position marker someplace and reference it in the function to select the current iteration AS_CLASS then it will work.
You received this message because you are subscribed to the Google Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opendatakit...@googlegroups.com.
You received this message because you are subscribed to the Google Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opendatakit...@googlegroups.com.
@mitch, good point. That's very unfortunate. I can now see that this would
be a blocker for (finally) introducing correct relative XPath syntax for
nodes inside repeats. I guess we'd need fuller XPath support to generate
the proper syntax for cascading filters inside repeats.
On Thursday, February 6, 2014 10:34:40 AM UTC-7, Mitch Sundt wrote:
The bind:
(1) if XLSForm changes to use relative paths, this would fix most
people's issues with things breaking within repeat groups.
but,
(2) the larger problem is the expressiveness of XPath notation. While you
need relative paths to correctly reference values within repeat groups, if
you then use relative paths within the filter expresions of a cascading
select (external itemset), the relative value is interpreted relative to
that external dataset, not relative to your survey values.
i.e., you need absolute references when using cascading selects.
The end result is that changing (1) to fix repeat groups will introduce
failures in cascading selects (2) all the time.
So we are stuck in our current situation where we have usable cascading
selects but repeat groups are generally difficult to get right and using
cascading selects within them is very hard or impossible.
This is a prominent reason the ODK 2.0 tools have abandoned XForms and
XPath expressions, and turned to Javascript and HTML as the base
descriptive languages.
The tools shouldn't prevent people from doing what they want to do
because of a technology choice they don't generally care about.
Mitch
On Thu, Feb 6, 2014 at 5:18 AM, Christopher Robert chrisl...@gmail.comwrote:
John,
If you have two fields, field1 and field2, inside the same repeat group,
then you generally want field2 to reference field1 with a relative path
like "../field1" rather than with an absolute path like
"/formid/groupname/field1". That's the big-picture issue here: XLSForm
always uses absolute references, and it relies on ODK/JavaRosa resolving
those references based on the current context -- which works basically
everywhere except here, with these cascading-select filters. The issue is
that some people don't think that it should be fixed, because the absolute
paths aren't the correct approach: relative paths are the correct approach.
But then, as far as I could tell, relative paths actually don't work either
-- but you can correct me if I'm wrong, if you're able to get them to work.
Thanks for the comments Chris. I am hoping that this will come
soon............I am not famillar with the absolute XPath reference syntax
or I would try it as well. I will do some googling..........any ref on
this would be appreciated.
On Thu, Feb 6, 2014 at 4:41 AM, Christopher Robert < cro...@surveycto.com> wrote:
John,
I'm very sorry. We had the very same experience. The trouble is that
the context is just not quite right when it's evaluating the filter -- so
it always thinks that it's in the first iteration.
Mitch may be right that there's some kind of relative XPath reference
that will work in that context, but we couldn't find anything that worked
when we last struggled with it. The best fix for users would be to make it
so that absolute XPath references, of the style created by XLSForm, work
the same in this filter context as they do elsewhere -- but there is
resistance to that, because I guess that it's not the way the
JavaRosa/XForm standard was meant to work. But then I haven't seen any
other fix or work-around either.
SurveyCTO users have been working around this by using our "dynamic
search-and-select" feature, whereby multiple-choice options are pulled
dynamically from a pre-loaded .csv file. We're working with Nafundi and
University of Washington on a deal to open-source our pre-loading features,
so I hope that that work-around will become available to non-SurveyCTO
users in the relatively near future. Then I guess everybody can more easily
live without this fix.
Chris this is absolutely infuriating .......................
using the index-repeat function I can set the filter-select column
within the group-repeat to the correct value of the cascade-select
value.....I switched it back to a regular select and placed a calculated
field in between just to see if the value was indeed correct.........it is
correct for each iteration just no love. even though the value seems to be
passed to the select-filter column the first value is the only one getting
selected............not sure what is going on.......
this is my select-filter syntax......works perfect on the first
try........
if I put this into a calculate field I get the correct value every
time...........it just will not apparently pass the value to the
select-filter column..............
I will attach an example of the file..........need to pair it down a
bit.
On Tuesday, February 4, 2014 7:41:27 AM UTC-7, Christopher Robert wrote:
John,
This has been filed as an issue at https://code.google.com/p/o
pendatakit/issues/detail?id=886. There was a very long email
discussion that followed the creation of that issue, and unfortunately I'm
not aware of any XPath syntax that actually works. If you find that using a
relative reference does actually work, please post a comment to https://code.google.com/p/opendatakit/issues/detail?id=886. Maybe
there is a patch to XLSForm that we could make, to facilitate these
filtered choice lists within repeat groups. As things stand, it's a major
issue.
not an issue if it works.......any docs on relative path
syntax?........I would be using the filter column as
[path][field]position(..) sound about right to you..
On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
See the list for issues around repeat groups. You likely need to
move away from the ${} syntax and use relative path (../group_asset) naming
within a repeat group.
This is a shortcoming of the code emitted by XLSForm.
I have ran into the cascading select issue with repeat groups. I
have tried to build a cascading select to parse down the selection list and
it works quite well.........until the second iteration of the repeat is
entered.......everything is fine cascade select works okay but it still
selects the filter for the first iteration even if a different parameter
is selected.....
example
iteration(1) AS_CLASS(1)=Shop cascade_select options
for Shop are presented.........
iteration(2) AS_CLASS(2)=landscape cascade_select options
for Shop are presented.......other than the ones expected from landscape
my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS},
${group_Asset}, position(..))
I really need this to work unless someone else has another
option.......leaving a 1000 option scroll list is not an option for me.
I don't mind doing some work to make this right but I do not have
a clue what to look for............relational position is what looks to be
a miss in this. if I could place a position marker someplace and reference
it in the function to select the current iteration AS_CLASS then it will
work.
select_one class AS_CLASS Asset Group
select_one eq_type ASSETTYPE Asset Type Code
You received this message because you are subscribed to the
Google Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to opendatakit...@googlegroups.com.
You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to opendatakit...@googlegroups.com.
You received this message because you are subscribed to a topic in the
Google Groups "ODK Community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/opendatakit/Ehu0lscXN8E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to opendatakit...@googlegroups.com.
Just checked it on my device.........same issue. Works great for the first
group instance but gives you an error on the second group.
xpath evaluation: type mismatch nodeset has more than one
no[instance(Cascade using relative filter
values)/cascading_repeat[1];instance(cascades using relative filter
values0/cascading_repeats[2]/country[1];connot convert to value
This is what I tried first........and it works great on
enkoto..........just not on my device
Any ideas as to why?
···
On Fri, Feb 7, 2014 at 9:32 PM, Martijn van de Rijdt wrote:
Yes, it is made with xls forms. See the link at the top of the form.
Nothing special though, but it works in enketo.
On Feb 7, 2014 7:21 PM, "John Harper" jharper1986@gmail.com wrote:
Xavctly.......
Will this work in xlsforms?
I will look at it better when I get back to my pc
Sent from my iPhone
On Feb 7, 2014, at 12:16 PM, Martijn van de Rijdt martijn@enketo.org wrote:
@mitch, good point. That's very unfortunate. I can now see that this
would be a blocker for (finally) introducing correct relative XPath syntax
for nodes inside repeats. I guess we'd need fuller XPath support to
generate the proper syntax for cascading filters inside repeats.
On Thursday, February 6, 2014 10:34:40 AM UTC-7, Mitch Sundt wrote:
The bind:
(1) if XLSForm changes to use relative paths, this would fix most
people's issues with things breaking within repeat groups.
but,
(2) the larger problem is the expressiveness of XPath notation. While
you need relative paths to correctly reference values within repeat groups,
if you then use relative paths within the filter expresions of a cascading
select (external itemset), the relative value is interpreted relative to
that external dataset, not relative to your survey values.
i.e., you need absolute references when using cascading selects.
The end result is that changing (1) to fix repeat groups will introduce
failures in cascading selects (2) all the time.
So we are stuck in our current situation where we have usable cascading
selects but repeat groups are generally difficult to get right and using
cascading selects within them is very hard or impossible.
This is a prominent reason the ODK 2.0 tools have abandoned XForms and
XPath expressions, and turned to Javascript and HTML as the base
descriptive languages.
The tools shouldn't prevent people from doing what they want to do
because of a technology choice they don't generally care about.
Mitch
On Thu, Feb 6, 2014 at 5:18 AM, Christopher Robert chrisl...@gmail.comwrote:
John,
If you have two fields, field1 and field2, inside the same repeat
group, then you generally want field2 to reference field1 with a relative
path like "../field1" rather than with an absolute path like
"/formid/groupname/field1". That's the big-picture issue here: XLSForm
always uses absolute references, and it relies on ODK/JavaRosa resolving
those references based on the current context -- which works basically
everywhere except here, with these cascading-select filters. The issue is
that some people don't think that it should be fixed, because the absolute
paths aren't the correct approach: relative paths are the correct approach.
But then, as far as I could tell, relative paths actually don't work either
-- but you can correct me if I'm wrong, if you're able to get them to work.
Thanks for the comments Chris. I am hoping that this will come
soon............I am not famillar with the absolute XPath reference syntax
or I would try it as well. I will do some googling..........any ref on
this would be appreciated.
On Thu, Feb 6, 2014 at 4:41 AM, Christopher Robert < cro...@surveycto.com> wrote:
John,
I'm very sorry. We had the very same experience. The trouble is that
the context is just not quite right when it's evaluating the filter -- so
it always thinks that it's in the first iteration.
Mitch may be right that there's some kind of relative XPath reference
that will work in that context, but we couldn't find anything that worked
when we last struggled with it. The best fix for users would be to make it
so that absolute XPath references, of the style created by XLSForm, work
the same in this filter context as they do elsewhere -- but there is
resistance to that, because I guess that it's not the way the
JavaRosa/XForm standard was meant to work. But then I haven't seen any
other fix or work-around either.
SurveyCTO users have been working around this by using our "dynamic
search-and-select" feature, whereby multiple-choice options are pulled
dynamically from a pre-loaded .csv file. We're working with Nafundi and
University of Washington on a deal to open-source our pre-loading features,
so I hope that that work-around will become available to non-SurveyCTO
users in the relatively near future. Then I guess everybody can more easily
live without this fix.
Chris this is absolutely infuriating .......................
using the index-repeat function I can set the filter-select column
within the group-repeat to the correct value of the cascade-select
value.....I switched it back to a regular select and placed a calculated
field in between just to see if the value was indeed correct.........it is
correct for each iteration just no love. even though the value seems to be
passed to the select-filter column the first value is the only one getting
selected............not sure what is going on.......
this is my select-filter syntax......works perfect on the first
try........
if I put this into a calculate field I get the correct value every
time...........it just will not apparently pass the value to the
select-filter column..............
I will attach an example of the file..........need to pair it down a
bit.
On Tuesday, February 4, 2014 7:41:27 AM UTC-7, Christopher Robert wrote:
John,
This has been filed as an issue at https://code.google.com/p/o
pendatakit/issues/detail?id=886. There was a very long email
discussion that followed the creation of that issue, and unfortunately I'm
not aware of any XPath syntax that actually works. If you find that using a
relative reference does actually work, please post a comment to https://code.google.com/p/opendatakit/issues/detail?id=886. Maybe
there is a patch to XLSForm that we could make, to facilitate these
filtered choice lists within repeat groups. As things stand, it's a major
issue.
not an issue if it works.......any docs on relative path
syntax?........I would be using the filter column as
[path][field]position(..) sound about right to you..
On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
See the list for issues around repeat groups. You likely need to
move away from the ${} syntax and use relative path (../group_asset) naming
within a repeat group.
This is a shortcoming of the code emitted by XLSForm.
I have ran into the cascading select issue with repeat groups. I
have tried to build a cascading select to parse down the selection list and
it works quite well.........until the second iteration of the repeat is
entered.......everything is fine cascade select works okay but it still
selects the filter for the first iteration even if a different parameter
is selected.....
example
iteration(1) AS_CLASS(1)=Shop cascade_select options
for Shop are presented.........
iteration(2) AS_CLASS(2)=landscape cascade_select options
for Shop are presented.......other than the ones expected from landscape
my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS},
${group_Asset}, position(..))
I really need this to work unless someone else has another
option.......leaving a 1000 option scroll list is not an option for me.
I don't mind doing some work to make this right but I do not
have a clue what to look for............relational position is what looks
to be a miss in this. if I could place a position marker someplace and
reference it in the function to select the current iteration AS_CLASS then
it will work.
select_one class AS_CLASS Asset Group
select_one eq_type ASSETTYPE Asset Type Code
You received this message because you are subscribed to the
Google Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to opendatakit...@googlegroups.com.
You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to opendatakit...@googlegroups.com.
You received this message because you are subscribed to a topic in
the Google Groups "ODK Community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/opendatakit/Ehu0lscXN8E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to opendatakit...@googlegroups.com.
Do you mean you checked in ODK Collect on your device or on Enketo?
Sorry, I didn't mean to suggest that the sample form would work on ODK
Collect. As Mitch and Chris mentioned it won't work in ODK Collect atm.
Cheers,
Martijn
···
On Friday, February 7, 2014 10:54:40 PM UTC-7, John Harper wrote:
>
> Just checked it on my device.........same issue. Works great for the
> first group instance but gives you an error on the second group.
> xpath evaluation: type mismatch nodeset has more than one
> no[instance(Cascade using relative filter
> values)/cascading_repeat[1];instance(cascades using relative filter
> values0/cascading_repeats[2]/country[1];connot convert to value
>
>
> This is what I tried first........and it works great on
> enkoto..........just not on my device
>
> Any ideas as to why?
>
>
>
> On Fri, Feb 7, 2014 at 9:32 PM, Martijn van de Rijdt <mar...@enketo.org wrote:
>
>> Yes, it is made with xls forms. See the link at the top of the form.
>> Nothing special though, but it works in enketo.
>> On Feb 7, 2014 7:21 PM, "John Harper" <jharp...@gmail.com > wrote:
>>
>>> Xavctly.......
>>>
>>> Will this work in xlsforms?
>>>
>>> I will look at it better when I get back to my pc
>>>
>>> Sent from my iPhone
>>>
>>> On Feb 7, 2014, at 12:16 PM, Martijn van de Rijdt <mar...@enketo.org> wrote:
>>>
>>> @john, is this what you're trying to achieve:
>>> https://zlbyk.enketo.formhub.org/webform? (the GDocs link is at the top
>>> of the form).
>>>
>>> @mitch, good point. That's very unfortunate. I can now see that this
>>> would be a blocker for (finally) introducing correct relative XPath syntax
>>> for nodes inside repeats. I guess we'd need fuller XPath support to
>>> generate the proper syntax for cascading filters inside repeats.
>>>
>>>
>>> On Thursday, February 6, 2014 10:34:40 AM UTC-7, Mitch Sundt wrote:
>>>>
>>>> The bind:
>>>>
>>>> (1) if XLSForm changes to use relative paths, this would fix most
>>>> people's issues with things breaking within repeat groups.
>>>>
>>>> but,
>>>>
>>>> (2) the larger problem is the expressiveness of XPath notation. While
>>>> you need relative paths to correctly reference values within repeat groups,
>>>> if you then use relative paths within the filter expresions of a cascading
>>>> select (external itemset), the relative value is interpreted relative to
>>>> that external dataset, not relative to your survey values.
>>>>
>>>> i.e., you need absolute references when using cascading selects.
>>>>
>>>> ----
>>>> The end result is that changing (1) to fix repeat groups will introduce
>>>> failures in cascading selects (2) *all the time*.
>>>>
>>>> So we are stuck in our current situation where we have usable cascading
>>>> selects but repeat groups are generally difficult to get right and using
>>>> cascading selects within them is very hard or impossible.
>>>> ==========
>>>>
>>>> This is a prominent reason the ODK 2.0 tools have abandoned XForms and
>>>> XPath expressions, and turned to Javascript and HTML as the base
>>>> descriptive languages.
>>>>
>>>> The tools shouldn't prevent people from doing what they want to do
>>>> because of a technology choice they don't generally care about.
>>>>
>>>> Mitch
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Feb 6, 2014 at 5:18 AM, Christopher Robert >>>
>>>>> John,
>>>>>
>>>>> If you have two fields, field1 and field2, inside the same repeat
>>>>> group, then you generally want field2 to reference field1 with a relative
>>>>> path like "../field1" rather than with an absolute path like
>>>>> "/formid/groupname/field1". That's the big-picture issue here: XLSForm
>>>>> always uses absolute references, and it relies on ODK/JavaRosa resolving
>>>>> those references based on the current context -- which works basically
>>>>> everywhere except here, with these cascading-select filters. The issue is
>>>>> that some people don't think that it should be fixed, because the absolute
>>>>> paths aren't the correct approach: relative paths are the correct approach.
>>>>> But then, as far as I could tell, relative paths actually don't work either
>>>>> -- but you can correct me if I'm wrong, if you're able to get them to work.
>>>>>
>>>>> Best,
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 6, 2014 at 7:54 AM, John Harper wrote:
>>>>>
>>>>>> Thanks for the comments Chris. I am hoping that this will come
>>>>>> soon............I am not famillar with the absolute XPath reference syntax
>>>>>> or I would try it as well. I will do some googling..........any ref on
>>>>>> this would be appreciated.
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 6, 2014 at 4:41 AM, Christopher Robert < cro...@surveycto.com> wrote:
>>>>>>
>>>>>>> John,
>>>>>>>
>>>>>>> I'm very sorry. We had the very same experience. The trouble is that
>>>>>>> the context is just not quite right when it's evaluating the filter -- so
>>>>>>> it always thinks that it's in the first iteration.
>>>>>>>
>>>>>>> Mitch may be right that there's some kind of relative XPath
>>>>>>> reference that will work in that context, but we couldn't find anything
>>>>>>> that worked when we last struggled with it. The best fix for users would be
>>>>>>> to make it so that absolute XPath references, of the style created by
>>>>>>> XLSForm, work the same in this filter context as they do elsewhere -- but
>>>>>>> there is resistance to that, because I guess that it's not the way the
>>>>>>> JavaRosa/XForm standard was meant to work. But then I haven't seen any
>>>>>>> other fix or work-around either.
>>>>>>>
>>>>>>> SurveyCTO users have been working around this by using our "dynamic
>>>>>>> search-and-select" feature, whereby multiple-choice options are pulled
>>>>>>> dynamically from a pre-loaded .csv file. We're working with Nafundi and
>>>>>>> University of Washington on a deal to open-source our pre-loading features,
>>>>>>> so I hope that that work-around will become available to non-SurveyCTO
>>>>>>> users in the relatively near future. Then I guess everybody can more easily
>>>>>>> live without this fix.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Feb 5, 2014 at 11:14 PM, John Harper wrote:
>>>>>>>
>>>>>>>> Chris this is absolutely infuriating .......................
>>>>>>>>
>>>>>>>> using the index-repeat function I can set the filter-select column
>>>>>>>> within the group-repeat to the correct value of the cascade-select
>>>>>>>> value.....I switched it back to a regular select and placed a calculated
>>>>>>>> field in between just to see if the value was indeed correct.........it is
>>>>>>>> correct for each iteration just no love. even though the value seems to be
>>>>>>>> passed to the select-filter column the first value is the only one getting
>>>>>>>> selected............not sure what is going on.......
>>>>>>>>
>>>>>>>> this is my select-filter syntax......works perfect on the first
>>>>>>>> try........
>>>>>>>>
>>>>>>>> class1=indexed-repeat(${AS_CLASS}, ${group_Asset},position(..))
>>>>>>>>
>>>>>>>> if I put this into a calculate field I get the correct value every
>>>>>>>> time...........it just will not apparently pass the value to the
>>>>>>>> select-filter column..............
>>>>>>>>
>>>>>>>>
>>>>>>>> I will attach an example of the file..........need to pair it down
>>>>>>>> a bit.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tuesday, February 4, 2014 7:41:27 AM UTC-7, Christopher Robert wrote:
>>>>>>>>
>>>>>>>>> John,
>>>>>>>>>
>>>>>>>>> This has been filed as an issue at https://code.google.com/p/o
>>>>>>>>> pendatakit/issues/detail?id=886. There was a very long email
>>>>>>>>> discussion that followed the creation of that issue, and unfortunately I'm
>>>>>>>>> not aware of any XPath syntax that actually works. If you find that using a
>>>>>>>>> relative reference does actually work, please post a comment to
>>>>>>>>> https://code.google.com/p/opendatakit/issues/detail?id=886. Maybe
>>>>>>>>> there is a patch to XLSForm that we could make, to facilitate these
>>>>>>>>> filtered choice lists within repeat groups. As things stand, it's a major
>>>>>>>>> issue.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Feb 4, 2014 at 9:33 AM, John Harper wrote:
>>>>>>>>>
>>>>>>>>>> Thanks Mitch.......I will give it a go.
>>>>>>>>>>
>>>>>>>>>> not an issue if it works.......any docs on relative path
>>>>>>>>>> syntax?........I would be using the filter column as
>>>>>>>>>> [path][field]position(..) sound about right to you..
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
>>>>>>>>>>
>>>>>>>>>>> See the list for issues around repeat groups. You likely need to
>>>>>>>>>>> move away from the ${} syntax and use relative path (../group_asset) naming
>>>>>>>>>>> within a repeat group.
>>>>>>>>>>>
>>>>>>>>>>> This is a shortcoming of the code emitted by XLSForm.
>>>>>>>>>>>
>>>>>>>>>>> Mitch
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Feb 1, 2014 at 10:59 AM, John Harper >>>>>>>>>>
>>>>>>>>>>>> I have ran into the cascading select issue with repeat groups.
>>>>>>>>>>>> I have tried to build a cascading select to parse down the selection list
>>>>>>>>>>>> and it works quite well.........until the second iteration of the repeat is
>>>>>>>>>>>> entered.......everything is fine cascade select works okay but it still
>>>>>>>>>>>> selects the filter for the first iteration even if a different parameter
>>>>>>>>>>>> is selected.....
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> example
>>>>>>>>>>>>
>>>>>>>>>>>> iteration(1) AS_CLASS(1)=Shop cascade_select options
>>>>>>>>>>>> for Shop are presented.........
>>>>>>>>>>>>
>>>>>>>>>>>> iteration(2) AS_CLASS(2)=landscape cascade_select options
>>>>>>>>>>>> for Shop are presented.......other than the ones expected from landscape
>>>>>>>>>>>>
>>>>>>>>>>>> my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS},
>>>>>>>>>>>> ${group_Asset}, position(..))
>>>>>>>>>>>>
>>>>>>>>>>>> I really need this to work unless someone else has another
>>>>>>>>>>>> option.......leaving a 1000 option scroll list is not an option for me.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't mind doing some work to make this right but I do not
>>>>>>>>>>>> have a clue what to look for............relational position is what looks
>>>>>>>>>>>> to be a miss in this. if I could place a position marker someplace and
>>>>>>>>>>>> reference it in the function to select the current iteration AS_CLASS then
>>>>>>>>>>>> it will work.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> select_one class AS_CLASS Asset Group
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> select_one eq_type ASSETTYPE Asset Type Code
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> --
>>>>>>>>>>>> Post: opend...@googlegroups.com
>>>>>>>>>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>>>>>>>>>>
>>>>>>>>>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>> Google Groups "ODK Community" group.
>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>>> it, send an email to opendatakit...@googlegroups.com.
>>>>>>>>>>>>
>>>>>>>>>>>> For more options, visit https://groups.google.com/grou
>>>>>>>>>>>> ps/opt_out.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>> Google Groups "ODK Community" group.
>>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>>> send an email to opendatakit...@googlegroups.com.
>>>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>> --
>>>>>>>> Post: opend...@googlegroups.com
>>>>>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>>>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>>>>>
>>>>>>>> ---
>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>> Groups "ODK Community" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an email to opendatakit...@googlegroups.com.
>>>>>>>>
>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> --
>>>>>>> Post: opend...@googlegroups.com
>>>>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>>>>
>>>>>>> ---
>>>>>>> You received this message because you are subscribed to a topic in
>>>>>>> the Google Groups "ODK Community" group.
>>>>>>> To unsubscribe from this topic, visit https://groups.google.com/d/
>>>>>>> topic/opendatakit/Ehu0lscXN8E/unsubscribe.
>>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>>> opendatakit...@googlegroups.com.
>>>>>>>
>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> Post: opend...@googlegroups.com
>>>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>>>
>>>>>> ---
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "ODK Community" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to opendatakit...@googlegroups.com.
>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>
>>>>>
>>>>> --
>>>>> --
>>>>> Post: opend...@googlegroups.com
>>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>>
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "ODK Community" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to opendatakit...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "ODK Community" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/opendatakit/Ehu0lscXN8E/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> opendatakit...@googlegroups.com .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>> --
>>> --
>>> Post: opend...@googlegroups.com
>>> Unsubscribe: opendatakit...@googlegroups.com
>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "ODK Community" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/opendatakit/Ehu0lscXN8E/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> opendatakit...@googlegroups.com .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>> --
>> --
>> Post: opend...@googlegroups.com
>> Unsubscribe: opendatakit...@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ODK Community" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/opendatakit/Ehu0lscXN8E/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> opendatakit...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
do I have to run a different mobile application for this to work rather
than ODK Collect? The idea was to use open source items........the is
always no budget for data collection and this was a no
brainer.............if I have to support license cost this is a dead deal.
···
On Sun, Feb 9, 2014 at 9:36 AM, Martijn van de Rijdt wrote:
Hi John,
Do you mean you checked in ODK Collect on your device or on Enketo?
Sorry, I didn't mean to suggest that the sample form would work on ODK
Collect. As Mitch and Chris mentioned it won't work in ODK Collect atm.
Cheers,
Martijn
On Friday, February 7, 2014 10:54:40 PM UTC-7, John Harper wrote:
Just checked it on my device.........same issue. Works great for the
first group instance but gives you an error on the second group.
xpath evaluation: type mismatch nodeset has more than one
no[instance(Cascade using relative filter values)/cascading_repeat[1];instance(cascades
using relative filter values0/cascading_repeats[2]/country[1];connot
convert to value
This is what I tried first........and it works great on
enkoto..........just not on my device
Any ideas as to why?
On Fri, Feb 7, 2014 at 9:32 PM, Martijn van de Rijdt mar...@enketo.orgwrote:
Yes, it is made with xls forms. See the link at the top of the form.
Nothing special though, but it works in enketo.
On Feb 7, 2014 7:21 PM, "John Harper" jharp...@gmail.com wrote:
Xavctly.......
Will this work in xlsforms?
I will look at it better when I get back to my pc
Sent from my iPhone
On Feb 7, 2014, at 12:16 PM, Martijn van de Rijdt mar...@enketo.org wrote:
@mitch, good point. That's very unfortunate. I can now see that this
would be a blocker for (finally) introducing correct relative XPath syntax
for nodes inside repeats. I guess we'd need fuller XPath support to
generate the proper syntax for cascading filters inside repeats.
On Thursday, February 6, 2014 10:34:40 AM UTC-7, Mitch Sundt wrote:
The bind:
(1) if XLSForm changes to use relative paths, this would fix most
people's issues with things breaking within repeat groups.
but,
(2) the larger problem is the expressiveness of XPath notation. While
you need relative paths to correctly reference values within repeat groups,
if you then use relative paths within the filter expresions of a cascading
select (external itemset), the relative value is interpreted relative to
that external dataset, not relative to your survey values.
i.e., you need absolute references when using cascading selects.
The end result is that changing (1) to fix repeat groups will
introduce failures in cascading selects (2) all the time.
So we are stuck in our current situation where we have usable
cascading selects but repeat groups are generally difficult to get right
and using cascading selects within them is very hard or impossible.
This is a prominent reason the ODK 2.0 tools have abandoned XForms and
XPath expressions, and turned to Javascript and HTML as the base
descriptive languages.
The tools shouldn't prevent people from doing what they want to do
because of a technology choice they don't generally care about.
Mitch
On Thu, Feb 6, 2014 at 5:18 AM, Christopher Robert < chrisl...@gmail.com> wrote:
John,
If you have two fields, field1 and field2, inside the same repeat
group, then you generally want field2 to reference field1 with a relative
path like "../field1" rather than with an absolute path like
"/formid/groupname/field1". That's the big-picture issue here: XLSForm
always uses absolute references, and it relies on ODK/JavaRosa resolving
those references based on the current context -- which works basically
everywhere except here, with these cascading-select filters. The issue is
that some people don't think that it should be fixed, because the absolute
paths aren't the correct approach: relative paths are the correct approach.
But then, as far as I could tell, relative paths actually don't work either
-- but you can correct me if I'm wrong, if you're able to get them to work.
Thanks for the comments Chris. I am hoping that this will come
soon............I am not famillar with the absolute XPath reference syntax
or I would try it as well. I will do some googling..........any ref on
this would be appreciated.
On Thu, Feb 6, 2014 at 4:41 AM, Christopher Robert < cro...@surveycto.com> wrote:
John,
I'm very sorry. We had the very same experience. The trouble is
that the context is just not quite right when it's evaluating the filter --
so it always thinks that it's in the first iteration.
Mitch may be right that there's some kind of relative XPath
reference that will work in that context, but we couldn't find anything
that worked when we last struggled with it. The best fix for users would be
to make it so that absolute XPath references, of the style created by
XLSForm, work the same in this filter context as they do elsewhere -- but
there is resistance to that, because I guess that it's not the way the
JavaRosa/XForm standard was meant to work. But then I haven't seen any
other fix or work-around either.
SurveyCTO users have been working around this by using our "dynamic
search-and-select" feature, whereby multiple-choice options are pulled
dynamically from a pre-loaded .csv file. We're working with Nafundi and
University of Washington on a deal to open-source our pre-loading features,
so I hope that that work-around will become available to non-SurveyCTO
users in the relatively near future. Then I guess everybody can more easily
live without this fix.
Chris this is absolutely infuriating .......................
using the index-repeat function I can set the filter-select column
within the group-repeat to the correct value of the cascade-select
value.....I switched it back to a regular select and placed a calculated
field in between just to see if the value was indeed correct.........it is
correct for each iteration just no love. even though the value seems to be
passed to the select-filter column the first value is the only one getting
selected............not sure what is going on.......
this is my select-filter syntax......works perfect on the first
try........
if I put this into a calculate field I get the correct value every
time...........it just will not apparently pass the value to the
select-filter column..............
I will attach an example of the file..........need to pair it down
a bit.
On Tuesday, February 4, 2014 7:41:27 AM UTC-7, Christopher Robert wrote:
John,
This has been filed as an issue at https://code.google.com/p/o
pendatakit/issues/detail?id=886. There was a very long email
discussion that followed the creation of that issue, and unfortunately I'm
not aware of any XPath syntax that actually works. If you find that using a
relative reference does actually work, please post a comment to https://code.google.com/p/opendatakit/issues/detail?id=886.
Maybe there is a patch to XLSForm that we could make, to facilitate these
filtered choice lists within repeat groups. As things stand, it's a major
issue.
not an issue if it works.......any docs on relative path
syntax?........I would be using the filter column as
[path][field]position(..) sound about right to you..
On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
See the list for issues around repeat groups. You likely need
to move away from the ${} syntax and use relative path (../group_asset)
naming within a repeat group.
This is a shortcoming of the code emitted by XLSForm.
Mitch
On Sat, Feb 1, 2014 at 10:59 AM, John Harper < jharp...@gmail.com> wrote:
I have ran into the cascading select issue with repeat groups.
I have tried to build a cascading select to parse down the selection list
and it works quite well.........until the second iteration of the repeat is
entered.......everything is fine cascade select works okay but it still
selects the filter for the first iteration even if a different parameter
is selected.....
example
iteration(1) AS_CLASS(1)=Shop cascade_select
options for Shop are presented.........
iteration(2) AS_CLASS(2)=landscape cascade_select options
for Shop are presented.......other than the ones expected from landscape
my filter questions in xlsforms class1=indexed-repeat(${AS_CLASS},
${group_Asset}, position(..))
I really need this to work unless someone else has another
option.......leaving a 1000 option scroll list is not an option for me.
I don't mind doing some work to make this right but I do not
have a clue what to look for............relational position is what looks
to be a miss in this. if I could place a position marker someplace and
reference it in the function to select the current iteration AS_CLASS then
it will work.
select_one class AS_CLASS Asset Group
select_one eq_type ASSETTYPE Asset Type Code
You received this message because you are subscribed to the
Google Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to opendatakit...@googlegroups.com.
You received this message because you are subscribed to the Google
Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to opendatakit...@googlegroups.com.
You received this message because you are subscribed to a topic in
the Google Groups "ODK Community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/opendatakit/Ehu0lscXN8E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to opendatakit...@googlegroups.com.
The web page IS the application :). It just needs a modern browser. Each
form gets its own unique URL. It works on any device and launches offline
too (after you've opened it once online). It saves data in your browser
(for weeks if necessary and you can shut down your device and browser).
When you connect to the Internet just open the page and the saved records
will be uploaded.
To get an idea of whether Enketo is suitable for you for some forms, you
may want to first check out the table on https://enketo.org/openrosa and
then just test your forms in both clients.
Cheers,
Martijn
···
On Sunday, February 9, 2014 9:48:40 AM UTC-7, John Harper wrote:
>
> do I have to run a different mobile application for this to work rather
> than ODK Collect? The idea was to use open source items........the is
> always no budget for data collection and this was a no
> brainer.............if I have to support license cost this is a dead deal.
>
>
>
> On Sun, Feb 9, 2014 at 9:36 AM, Martijn van de Rijdt <mar...@enketo.org wrote:
>
>> Hi John,
>>
>> Do you mean you checked in ODK Collect on your device or on Enketo?
>>
>> Sorry, I didn't mean to suggest that the sample form would work on ODK
>> Collect. As Mitch and Chris mentioned it won't work in ODK Collect atm.
>>
>> Cheers,
>> Martijn
>>
>> On Friday, February 7, 2014 10:54:40 PM UTC-7, John Harper wrote:
>>
>>> Just checked it on my device.........same issue. Works great for the
>>> first group instance but gives you an error on the second group.
>>> xpath evaluation: type mismatch nodeset has more than one
>>> no[instance(Cascade using relative filter values)/cascading_repeat[1];instance(cascades
>>> using relative filter values0/cascading_repeats[2]/country[1];connot
>>> convert to value
>>>
>>>
>>> This is what I tried first........and it works great on
>>> enkoto..........just not on my device
>>>
>>> Any ideas as to why?
>>>
>>>
>>>
>>> On Fri, Feb 7, 2014 at 9:32 PM, Martijn van de Rijdt wrote:
>>>
>>>> Yes, it is made with xls forms. See the link at the top of the form.
>>>> Nothing special though, but it works in enketo.
>>>> On Feb 7, 2014 7:21 PM, "John Harper" wrote:
>>>>
>>>>> Xavctly.......
>>>>>
>>>>> Will this work in xlsforms?
>>>>>
>>>>> I will look at it better when I get back to my pc
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Feb 7, 2014, at 12:16 PM, Martijn van de Rijdt wrote:
>>>>>
>>>>> @john, is this what you're trying to achieve: https://zlbyk.enketo.
>>>>> formhub.org/webform? (the GDocs link is at the top of the form).
>>>>>
>>>>> @mitch, good point. That's very unfortunate. I can now see that this
>>>>> would be a blocker for (finally) introducing correct relative XPath syntax
>>>>> for nodes inside repeats. I guess we'd need fuller XPath support to
>>>>> generate the proper syntax for cascading filters inside repeats.
>>>>>
>>>>>
>>>>> On Thursday, February 6, 2014 10:34:40 AM UTC-7, Mitch Sundt wrote:
>>>>>>
>>>>>> The bind:
>>>>>>
>>>>>> (1) if XLSForm changes to use relative paths, this would fix most
>>>>>> people's issues with things breaking within repeat groups.
>>>>>>
>>>>>> but,
>>>>>>
>>>>>> (2) the larger problem is the expressiveness of XPath notation. While
>>>>>> you need relative paths to correctly reference values within repeat groups,
>>>>>> if you then use relative paths within the filter expresions of a cascading
>>>>>> select (external itemset), the relative value is interpreted relative to
>>>>>> that external dataset, not relative to your survey values.
>>>>>>
>>>>>> i.e., you need absolute references when using cascading selects.
>>>>>>
>>>>>> ----
>>>>>> The end result is that changing (1) to fix repeat groups will
>>>>>> introduce failures in cascading selects (2) *all the time*.
>>>>>>
>>>>>> So we are stuck in our current situation where we have usable
>>>>>> cascading selects but repeat groups are generally difficult to get right
>>>>>> and using cascading selects within them is very hard or impossible.
>>>>>> ==========
>>>>>>
>>>>>> This is a prominent reason the ODK 2.0 tools have abandoned XForms
>>>>>> and XPath expressions, and turned to Javascript and HTML as the base
>>>>>> descriptive languages.
>>>>>>
>>>>>> The tools shouldn't prevent people from doing what they want to do
>>>>>> because of a technology choice they don't generally care about.
>>>>>>
>>>>>> Mitch
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 6, 2014 at 5:18 AM, Christopher Robert < chrisl...@gmail.com> wrote:
>>>>>>
>>>>>>> John,
>>>>>>>
>>>>>>> If you have two fields, field1 and field2, inside the same repeat
>>>>>>> group, then you generally want field2 to reference field1 with a relative
>>>>>>> path like "../field1" rather than with an absolute path like
>>>>>>> "/formid/groupname/field1". That's the big-picture issue here: XLSForm
>>>>>>> always uses absolute references, and it relies on ODK/JavaRosa resolving
>>>>>>> those references based on the current context -- which works basically
>>>>>>> everywhere except here, with these cascading-select filters. The issue is
>>>>>>> that some people don't think that it should be fixed, because the absolute
>>>>>>> paths aren't the correct approach: relative paths are the correct approach.
>>>>>>> But then, as far as I could tell, relative paths actually don't work either
>>>>>>> -- but you can correct me if I'm wrong, if you're able to get them to work.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 6, 2014 at 7:54 AM, John Harper wrote:
>>>>>>>
>>>>>>>> Thanks for the comments Chris. I am hoping that this will come
>>>>>>>> soon............I am not famillar with the absolute XPath reference syntax
>>>>>>>> or I would try it as well. I will do some googling..........any ref on
>>>>>>>> this would be appreciated.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 6, 2014 at 4:41 AM, Christopher Robert < cro...@surveycto.com> wrote:
>>>>>>>>
>>>>>>>>> John,
>>>>>>>>>
>>>>>>>>> I'm very sorry. We had the very same experience. The trouble is
>>>>>>>>> that the context is just not quite right when it's evaluating the filter --
>>>>>>>>> so it always thinks that it's in the first iteration.
>>>>>>>>>
>>>>>>>>> Mitch may be right that there's some kind of relative XPath
>>>>>>>>> reference that will work in that context, but we couldn't find anything
>>>>>>>>> that worked when we last struggled with it. The best fix for users would be
>>>>>>>>> to make it so that absolute XPath references, of the style created by
>>>>>>>>> XLSForm, work the same in this filter context as they do elsewhere -- but
>>>>>>>>> there is resistance to that, because I guess that it's not the way the
>>>>>>>>> JavaRosa/XForm standard was meant to work. But then I haven't seen any
>>>>>>>>> other fix or work-around either.
>>>>>>>>>
>>>>>>>>> SurveyCTO users have been working around this by using our
>>>>>>>>> "dynamic search-and-select" feature, whereby multiple-choice options are
>>>>>>>>> pulled dynamically from a pre-loaded .csv file. We're working with Nafundi
>>>>>>>>> and University of Washington on a deal to open-source our pre-loading
>>>>>>>>> features, so I hope that that work-around will become available to
>>>>>>>>> non-SurveyCTO users in the relatively near future. Then I guess everybody
>>>>>>>>> can more easily live without this fix.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Feb 5, 2014 at 11:14 PM, John Harper wrote:
>>>>>>>>>
>>>>>>>>>> Chris this is absolutely infuriating .......................
>>>>>>>>>>
>>>>>>>>>> using the index-repeat function I can set the filter-select
>>>>>>>>>> column within the group-repeat to the correct value of the cascade-select
>>>>>>>>>> value.....I switched it back to a regular select and placed a calculated
>>>>>>>>>> field in between just to see if the value was indeed correct.........it is
>>>>>>>>>> correct for each iteration just no love. even though the value seems to be
>>>>>>>>>> passed to the select-filter column the first value is the only one getting
>>>>>>>>>> selected............not sure what is going on.......
>>>>>>>>>>
>>>>>>>>>> this is my select-filter syntax......works perfect on the first
>>>>>>>>>> try........
>>>>>>>>>>
>>>>>>>>>> class1=indexed-repeat(${AS_CLASS}, ${group_Asset},position(..))
>>>>>>>>>>
>>>>>>>>>> if I put this into a calculate field I get the correct value
>>>>>>>>>> every time...........it just will not apparently pass the value to the
>>>>>>>>>> select-filter column..............
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I will attach an example of the file..........need to pair it
>>>>>>>>>> down a bit.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tuesday, February 4, 2014 7:41:27 AM UTC-7, Christopher Robert wrote:
>>>>>>>>>>
>>>>>>>>>>> John,
>>>>>>>>>>>
>>>>>>>>>>> This has been filed as an issue at https://code.google.com/p/o
>>>>>>>>>>> pendatakit/issues/detail?id=886. There was a very long email
>>>>>>>>>>> discussion that followed the creation of that issue, and unfortunately I'm
>>>>>>>>>>> not aware of any XPath syntax that actually works. If you find that using a
>>>>>>>>>>> relative reference does actually work, please post a comment to
>>>>>>>>>>> https://code.google.com/p/opendatakit/issues/detail?id=886.
>>>>>>>>>>> Maybe there is a patch to XLSForm that we could make, to facilitate these
>>>>>>>>>>> filtered choice lists within repeat groups. As things stand, it's a major
>>>>>>>>>>> issue.
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>>
>>>>>>>>>>> Chris
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Feb 4, 2014 at 9:33 AM, John Harper wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Thanks Mitch.......I will give it a go.
>>>>>>>>>>>>
>>>>>>>>>>>> not an issue if it works.......any docs on relative path
>>>>>>>>>>>> syntax?........I would be using the filter column as
>>>>>>>>>>>> [path][field]position(..) sound about right to you..
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> See the list for issues around repeat groups. You likely need
>>>>>>>>>>>>> to move away from the ${} syntax and use relative path (../group_asset)
>>>>>>>>>>>>> naming within a repeat group.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is a shortcoming of the code emitted by XLSForm.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Mitch
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sat, Feb 1, 2014 at 10:59 AM, John Harper < jharp...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have ran into the cascading select issue with repeat
>>>>>>>>>>>>>> groups. I have tried to build a cascading select to parse down the
>>>>>>>>>>>>>> selection list and it works quite well.........until the second iteration
>>>>>>>>>>>>>> of the repeat is entered.......everything is fine cascade select works okay
>>>>>>>>>>>>>> but it still selects the filter for the first iteration even if a different
>>>>>>>>>>>>>> parameter is selected.....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> example
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> iteration(1) AS_CLASS(1)=Shop cascade_select
>>>>>>>>>>>>>> options for Shop are presented.........
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> iteration(2) AS_CLASS(2)=landscape cascade_select
>>>>>>>>>>>>>> options for Shop are presented.......other than the ones expected from
>>>>>>>>>>>>>> landscape
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> my filter questions in xlsforms class1=indexed-repeat(${AS_
>>>>>>>>>>>>>> CLASS}, ${group_Asset}, position(..))
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I really need this to work unless someone else has another
>>>>>>>>>>>>>> option.......leaving a 1000 option scroll list is not an option for me.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't mind doing some work to make this right but I do not
>>>>>>>>>>>>>> have a clue what to look for............relational position is what looks
>>>>>>>>>>>>>> to be a miss in this. if I could place a position marker someplace and
>>>>>>>>>>>>>> reference it in the function to select the current iteration AS_CLASS then
>>>>>>>>>>>>>> it will work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> select_one class AS_CLASS Asset Group
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> select_one eq_type ASSETTYPE Asset Type Code
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Post: opend...@googlegroups.com
>>>>>>>>>>>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>>>> Google Groups "ODK Community" group.
>>>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>>>>> it, send an email to opendatakit...@googlegroups.com.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For more options, visit https://groups.google.com/grou
>>>>>>>>>>>>>> ps/opt_out.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>> Google Groups "ODK Community" group.
>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>>> it, send an email to opendatakit...@googlegroups.com.
>>>>>>>>>>>> For more options, visit https://groups.google.com/grou
>>>>>>>>>>>> ps/opt_out.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>> --
>>>>>>>>>> Post: opend...@googlegroups.com
>>>>>>>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>>>>>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>> Google Groups "ODK Community" group.
>>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>>> send an email to opendatakit...@googlegroups.com.
>>>>>>>>>>
>>>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> --
>>>>>>>>> Post: opend...@googlegroups.com
>>>>>>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>>>>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> You received this message because you are subscribed to a topic in
>>>>>>>>> the Google Groups "ODK Community" group.
>>>>>>>>> To unsubscribe from this topic, visit https://groups.google.com/d/
>>>>>>>>> topic/opendatakit/Ehu0lscXN8E/unsubscribe.
>>>>>>>>> To unsubscribe from this group and all its topics, send an email
>>>>>>>>> to opendatakit...@googlegroups.com.
>>>>>>>>>
>>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> --
>>>>>>>> Post: opend...@googlegroups.com
>>>>>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>>>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>>>>>
>>>>>>>> ---
>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>> Groups "ODK Community" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an email to opendatakit...@googlegroups.com.
>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> --
>>>>>>> Post: opend...@googlegroups.com
>>>>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>>>>
>>>>>>> ---
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "ODK Community" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to opendatakit...@googlegroups.com.
>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>> ---
>>>>> You received this message because you are subscribed to a topic in the
>>>>> Google Groups "ODK Community" group.
>>>>> To unsubscribe from this topic, visit https://groups.google.com/d/
>>>>> topic/opendatakit/Ehu0lscXN8E/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>> opendatakit...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>> --
>>>>> --
>>>>> Post: opend...@googlegroups.com
>>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>>
>>>>> ---
>>>>> You received this message because you are subscribed to a topic in the
>>>>> Google Groups "ODK Community" group.
>>>>> To unsubscribe from this topic, visit https://groups.google.com/d/
>>>>> topic/opendatakit/Ehu0lscXN8E/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>> opendatakit...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>> --
>>>> --
>>>> Post: opend...@googlegroups.com
>>>> Unsubscribe: opendatakit...@googlegroups.com
>>>> Options: http://groups.google.com/group/opendatakit?hl=en
>>>>
>>>> ---
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "ODK Community" group.
>>>> To unsubscribe from this topic, visit https://groups.google.com/d/
>>>> topic/opendatakit/Ehu0lscXN8E/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> opendatakit...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>
>>> --
>> --
>> Post: opend...@googlegroups.com
>> Unsubscribe: opendatakit...@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ODK Community" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/opendatakit/Ehu0lscXN8E/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> opendatakit...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
you know the drill.........they don't think the expense of collecting
things on paper then translating and massaging that data into a database is
worth expending any capital.......................short sighted i
think.......... I am trying to do this as a pilot to expose the wasted
time on the "Old way of doing things"
Thanks for all your help. I downloaded the virtual appliance of ODK
Collect but it is at 1.4 and does not have the Enketo options added to the
mix.......I will have to update the server to do this or use formhub for
the time being till I can get this working.
···
On Sun, Feb 9, 2014 at 10:06 AM, Martijn van de Rijdt wrote:
The web page IS the application :). It just needs a modern browser. Each
form gets its own unique URL. It works on any device and launches offline
too (after you've opened it once online). It saves data in your browser
(for weeks if necessary and you can shut down your device and browser).
When you connect to the Internet just open the page and the saved records
will be uploaded.
To get an idea of whether Enketo is suitable for you for some forms, you
may want to first check out the table on https://enketo.org/openrosa and
then just test your forms in both clients.
Cheers,
Martijn
On Sunday, February 9, 2014 9:48:40 AM UTC-7, John Harper wrote:
do I have to run a different mobile application for this to work rather
than ODK Collect? The idea was to use open source items........the is
always no budget for data collection and this was a no
brainer.............if I have to support license cost this is a dead deal.
On Sun, Feb 9, 2014 at 9:36 AM, Martijn van de Rijdt mar...@enketo.orgwrote:
Hi John,
Do you mean you checked in ODK Collect on your device or on Enketo?
Sorry, I didn't mean to suggest that the sample form would work on ODK
Collect. As Mitch and Chris mentioned it won't work in ODK Collect atm.
Cheers,
Martijn
On Friday, February 7, 2014 10:54:40 PM UTC-7, John Harper wrote:
Just checked it on my device.........same issue. Works great for the
first group instance but gives you an error on the second group.
xpath evaluation: type mismatch nodeset has more than one
no[instance(Cascade using relative filter values)/cascading_repeat[1];
instance(cascades using relative filter values0/cascading_repeats[2]/country[1];connot
convert to value
This is what I tried first........and it works great on
enkoto..........just not on my device
Any ideas as to why?
On Fri, Feb 7, 2014 at 9:32 PM, Martijn van de Rijdt <mar...@enketo.org wrote:
Yes, it is made with xls forms. See the link at the top of the form.
Nothing special though, but it works in enketo.
On Feb 7, 2014 7:21 PM, "John Harper" jharp...@gmail.com wrote:
Xavctly.......
Will this work in xlsforms?
I will look at it better when I get back to my pc
Sent from my iPhone
On Feb 7, 2014, at 12:16 PM, Martijn van de Rijdt mar...@enketo.org wrote:
@mitch, good point. That's very unfortunate. I can now see that this
would be a blocker for (finally) introducing correct relative XPath syntax
for nodes inside repeats. I guess we'd need fuller XPath support to
generate the proper syntax for cascading filters inside repeats.
On Thursday, February 6, 2014 10:34:40 AM UTC-7, Mitch Sundt wrote:
The bind:
(1) if XLSForm changes to use relative paths, this would fix most
people's issues with things breaking within repeat groups.
but,
(2) the larger problem is the expressiveness of XPath notation.
While you need relative paths to correctly reference values within repeat
groups, if you then use relative paths within the filter expresions of a
cascading select (external itemset), the relative value is interpreted
relative to that external dataset, not relative to your survey values.
i.e., you need absolute references when using cascading selects.
The end result is that changing (1) to fix repeat groups will
introduce failures in cascading selects (2) all the time.
So we are stuck in our current situation where we have usable
cascading selects but repeat groups are generally difficult to get right
and using cascading selects within them is very hard or impossible.
This is a prominent reason the ODK 2.0 tools have abandoned XForms
and XPath expressions, and turned to Javascript and HTML as the base
descriptive languages.
The tools shouldn't prevent people from doing what they want to do
because of a technology choice they don't generally care about.
Mitch
On Thu, Feb 6, 2014 at 5:18 AM, Christopher Robert < chrisl...@gmail.com> wrote:
John,
If you have two fields, field1 and field2, inside the same repeat
group, then you generally want field2 to reference field1 with a relative
path like "../field1" rather than with an absolute path like
"/formid/groupname/field1". That's the big-picture issue here: XLSForm
always uses absolute references, and it relies on ODK/JavaRosa resolving
those references based on the current context -- which works basically
everywhere except here, with these cascading-select filters. The issue is
that some people don't think that it should be fixed, because the absolute
paths aren't the correct approach: relative paths are the correct approach.
But then, as far as I could tell, relative paths actually don't work either
-- but you can correct me if I'm wrong, if you're able to get them to work.
Thanks for the comments Chris. I am hoping that this will come
soon............I am not famillar with the absolute XPath reference syntax
or I would try it as well. I will do some googling..........any ref on
this would be appreciated.
On Thu, Feb 6, 2014 at 4:41 AM, Christopher Robert < cro...@surveycto.com> wrote:
John,
I'm very sorry. We had the very same experience. The trouble is
that the context is just not quite right when it's evaluating the filter --
so it always thinks that it's in the first iteration.
Mitch may be right that there's some kind of relative XPath
reference that will work in that context, but we couldn't find anything
that worked when we last struggled with it. The best fix for users would be
to make it so that absolute XPath references, of the style created by
XLSForm, work the same in this filter context as they do elsewhere -- but
there is resistance to that, because I guess that it's not the way the
JavaRosa/XForm standard was meant to work. But then I haven't seen any
other fix or work-around either.
SurveyCTO users have been working around this by using our
"dynamic search-and-select" feature, whereby multiple-choice options are
pulled dynamically from a pre-loaded .csv file. We're working with Nafundi
and University of Washington on a deal to open-source our pre-loading
features, so I hope that that work-around will become available to
non-SurveyCTO users in the relatively near future. Then I guess everybody
can more easily live without this fix.
Chris this is absolutely infuriating .......................
using the index-repeat function I can set the filter-select
column within the group-repeat to the correct value of the cascade-select
value.....I switched it back to a regular select and placed a calculated
field in between just to see if the value was indeed correct.........it is
correct for each iteration just no love. even though the value seems to be
passed to the select-filter column the first value is the only one getting
selected............not sure what is going on.......
this is my select-filter syntax......works perfect on the first
try........
if I put this into a calculate field I get the correct value
every time...........it just will not apparently pass the value to the
select-filter column..............
I will attach an example of the file..........need to pair it
down a bit.
On Tuesday, February 4, 2014 7:41:27 AM UTC-7, Christopher Robert wrote:
John,
This has been filed as an issue at https://code.google.com/p/o
pendatakit/issues/detail?id=886. There was a very long email
discussion that followed the creation of that issue, and unfortunately I'm
not aware of any XPath syntax that actually works. If you find that using a
relative reference does actually work, please post a comment to https://code.google.com/p/opendatakit/issues/detail?id=886.
Maybe there is a patch to XLSForm that we could make, to facilitate these
filtered choice lists within repeat groups. As things stand, it's a major
issue.
not an issue if it works.......any docs on relative path
syntax?........I would be using the filter column as
[path][field]position(..) sound about right to you..
On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
See the list for issues around repeat groups. You likely need
to move away from the ${} syntax and use relative path (../group_asset)
naming within a repeat group.
This is a shortcoming of the code emitted by XLSForm.
Mitch
On Sat, Feb 1, 2014 at 10:59 AM, John Harper < jharp...@gmail.com> wrote:
I have ran into the cascading select issue with repeat
groups. I have tried to build a cascading select to parse down the
selection list and it works quite well.........until the second iteration
of the repeat is entered.......everything is fine cascade select works okay
but it still selects the filter for the first iteration even if a different
parameter is selected.....
example
iteration(1) AS_CLASS(1)=Shop cascade_select
options for Shop are presented.........
iteration(2) AS_CLASS(2)=landscape cascade_select
options for Shop are presented.......other than the ones expected from
landscape
my filter questions in xlsforms class1=indexed-repeat(${AS_
CLASS}, ${group_Asset}, position(..))
I really need this to work unless someone else has another
option.......leaving a 1000 option scroll list is not an option for me.
I don't mind doing some work to make this right but I do not
have a clue what to look for............relational position is what looks
to be a miss in this. if I could place a position marker someplace and
reference it in the function to select the current iteration AS_CLASS then
it will work.
select_one class AS_CLASS Asset Group
select_one eq_type ASSETTYPE Asset Type Code
You received this message because you are subscribed to the
Google Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to opendatakit...@googlegroups.com.
You received this message because you are subscribed to the
Google Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/grou
ps/opt_out.
You received this message because you are subscribed to the
Google Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to opendatakit...@googlegroups.com.
Good luck with the pilot. Seems like you should have a good chance of
succeeding in your mission! Indeed funny how person-hours are not an
'expense' sometimes ;).
···
On Sun, Feb 9, 2014 at 11:20 AM, John Harper wrote:
Thanks Martijn,
you know the drill.........they don't think the expense of collecting
things on paper then translating and massaging that data into a database is
worth expending any capital.......................short sighted i
think.......... I am trying to do this as a pilot to expose the wasted
time on the "Old way of doing things"
Thanks for all your help. I downloaded the virtual appliance of ODK
Collect but it is at 1.4 and does not have the Enketo options added to the
mix.......I will have to update the server to do this or use formhub for
the time being till I can get this working.
On Sun, Feb 9, 2014 at 10:06 AM, Martijn van de Rijdt martijn@enketo.orgwrote:
The web page IS the application :). It just needs a modern browser. Each
form gets its own unique URL. It works on any device and launches offline
too (after you've opened it once online). It saves data in your browser
(for weeks if necessary and you can shut down your device and browser).
When you connect to the Internet just open the page and the saved records
will be uploaded.
To get an idea of whether Enketo is suitable for you for some forms, you
may want to first check out the table on https://enketo.org/openrosa and
then just test your forms in both clients.
Cheers,
Martijn
On Sunday, February 9, 2014 9:48:40 AM UTC-7, John Harper wrote:
do I have to run a different mobile application for this to work rather
than ODK Collect? The idea was to use open source items........the is
always no budget for data collection and this was a no
brainer.............if I have to support license cost this is a dead deal.
On Sun, Feb 9, 2014 at 9:36 AM, Martijn van de Rijdt mar...@enketo.orgwrote:
Hi John,
Do you mean you checked in ODK Collect on your device or on Enketo?
Sorry, I didn't mean to suggest that the sample form would work on ODK
Collect. As Mitch and Chris mentioned it won't work in ODK Collect atm.
Cheers,
Martijn
On Friday, February 7, 2014 10:54:40 PM UTC-7, John Harper wrote:
Just checked it on my device.........same issue. Works great for the
first group instance but gives you an error on the second group.
xpath evaluation: type mismatch nodeset has more than one
no[instance(Cascade using relative filter values)/cascading_repeat[1];
instance(cascades using relative filter values0/cascading_repeats[2]/country[1];connot
convert to value
This is what I tried first........and it works great on
enkoto..........just not on my device
Any ideas as to why?
On Fri, Feb 7, 2014 at 9:32 PM, Martijn van de Rijdt < mar...@enketo.org> wrote:
Yes, it is made with xls forms. See the link at the top of the
form. Nothing special though, but it works in enketo.
On Feb 7, 2014 7:21 PM, "John Harper" jharp...@gmail.com wrote:
Xavctly.......
Will this work in xlsforms?
I will look at it better when I get back to my pc
Sent from my iPhone
On Feb 7, 2014, at 12:16 PM, Martijn van de Rijdt mar...@enketo.org wrote:
@mitch, good point. That's very unfortunate. I can now see that this
would be a blocker for (finally) introducing correct relative XPath syntax
for nodes inside repeats. I guess we'd need fuller XPath support to
generate the proper syntax for cascading filters inside repeats.
On Thursday, February 6, 2014 10:34:40 AM UTC-7, Mitch Sundt wrote:
The bind:
(1) if XLSForm changes to use relative paths, this would fix most
people's issues with things breaking within repeat groups.
but,
(2) the larger problem is the expressiveness of XPath notation.
While you need relative paths to correctly reference values within repeat
groups, if you then use relative paths within the filter expresions of a
cascading select (external itemset), the relative value is interpreted
relative to that external dataset, not relative to your survey values.
i.e., you need absolute references when using cascading selects.
The end result is that changing (1) to fix repeat groups will
introduce failures in cascading selects (2) all the time.
So we are stuck in our current situation where we have usable
cascading selects but repeat groups are generally difficult to get right
and using cascading selects within them is very hard or impossible.
This is a prominent reason the ODK 2.0 tools have abandoned XForms
and XPath expressions, and turned to Javascript and HTML as the base
descriptive languages.
The tools shouldn't prevent people from doing what they want to do
because of a technology choice they don't generally care about.
Mitch
On Thu, Feb 6, 2014 at 5:18 AM, Christopher Robert < chrisl...@gmail.com> wrote:
John,
If you have two fields, field1 and field2, inside the same repeat
group, then you generally want field2 to reference field1 with a relative
path like "../field1" rather than with an absolute path like
"/formid/groupname/field1". That's the big-picture issue here: XLSForm
always uses absolute references, and it relies on ODK/JavaRosa resolving
those references based on the current context -- which works basically
everywhere except here, with these cascading-select filters. The issue is
that some people don't think that it should be fixed, because the absolute
paths aren't the correct approach: relative paths are the correct approach.
But then, as far as I could tell, relative paths actually don't work either
-- but you can correct me if I'm wrong, if you're able to get them to work.
Thanks for the comments Chris. I am hoping that this will come
soon............I am not famillar with the absolute XPath reference syntax
or I would try it as well. I will do some googling..........any ref on
this would be appreciated.
On Thu, Feb 6, 2014 at 4:41 AM, Christopher Robert < cro...@surveycto.com> wrote:
John,
I'm very sorry. We had the very same experience. The trouble is
that the context is just not quite right when it's evaluating the filter --
so it always thinks that it's in the first iteration.
Mitch may be right that there's some kind of relative XPath
reference that will work in that context, but we couldn't find anything
that worked when we last struggled with it. The best fix for users would be
to make it so that absolute XPath references, of the style created by
XLSForm, work the same in this filter context as they do elsewhere -- but
there is resistance to that, because I guess that it's not the way the
JavaRosa/XForm standard was meant to work. But then I haven't seen any
other fix or work-around either.
SurveyCTO users have been working around this by using our
"dynamic search-and-select" feature, whereby multiple-choice options are
pulled dynamically from a pre-loaded .csv file. We're working with Nafundi
and University of Washington on a deal to open-source our pre-loading
features, so I hope that that work-around will become available to
non-SurveyCTO users in the relatively near future. Then I guess everybody
can more easily live without this fix.
Chris this is absolutely infuriating .......................
using the index-repeat function I can set the filter-select
column within the group-repeat to the correct value of the cascade-select
value.....I switched it back to a regular select and placed a calculated
field in between just to see if the value was indeed correct.........it is
correct for each iteration just no love. even though the value seems to be
passed to the select-filter column the first value is the only one getting
selected............not sure what is going on.......
this is my select-filter syntax......works perfect on the first
try........
if I put this into a calculate field I get the correct value
every time...........it just will not apparently pass the value to the
select-filter column..............
I will attach an example of the file..........need to pair it
down a bit.
On Tuesday, February 4, 2014 7:41:27 AM UTC-7, Christopher Robert wrote:
John,
This has been filed as an issue at https://code.google.com/p/o
pendatakit/issues/detail?id=886. There was a very long email
discussion that followed the creation of that issue, and unfortunately I'm
not aware of any XPath syntax that actually works. If you find that using a
relative reference does actually work, please post a comment to https://code.google.com/p/opendatakit/issues/detail?id=886.
Maybe there is a patch to XLSForm that we could make, to facilitate these
filtered choice lists within repeat groups. As things stand, it's a major
issue.
Best,
Chris
On Tue, Feb 4, 2014 at 9:33 AM, John Harper < jharp...@gmail.com> wrote:
Thanks Mitch.......I will give it a go.
not an issue if it works.......any docs on relative path
syntax?........I would be using the filter column as
[path][field]position(..) sound about right to you..
On Monday, February 3, 2014 10:21:46 AM UTC-7, Mitch Sundt wrote:
See the list for issues around repeat groups. You likely
need to move away from the ${} syntax and use relative path
(../group_asset) naming within a repeat group.
This is a shortcoming of the code emitted by XLSForm.
Mitch
On Sat, Feb 1, 2014 at 10:59 AM, John Harper < jharp...@gmail.com> wrote:
I have ran into the cascading select issue with repeat
groups. I have tried to build a cascading select to parse down the
selection list and it works quite well.........until the second iteration
of the repeat is entered.......everything is fine cascade select works okay
but it still selects the filter for the first iteration even if a different
parameter is selected.....
example
iteration(1) AS_CLASS(1)=Shop cascade_select
options for Shop are presented.........
iteration(2) AS_CLASS(2)=landscape cascade_select
options for Shop are presented.......other than the ones expected from
landscape
my filter questions in xlsforms class1=indexed-repeat(${AS_
CLASS}, ${group_Asset}, position(..))
I really need this to work unless someone else has another
option.......leaving a 1000 option scroll list is not an option for me.
I don't mind doing some work to make this right but I do
not have a clue what to look for............relational position is what
looks to be a miss in this. if I could place a position marker someplace
and reference it in the function to select the current iteration AS_CLASS
then it will work.
select_one class AS_CLASS Asset Group
select_one eq_type ASSETTYPE Asset Type Code
You received this message because you are subscribed to the
Google Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to opendatakit...@googlegroups.com.
You received this message because you are subscribed to the
Google Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to opendatakit...@googlegroups.com.
For more options, visit https://groups.google.com/grou
ps/opt_out.
You received this message because you are subscribed to the
Google Groups "ODK Community" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to opendatakit...@googlegroups.com.