The core library that many of the ODK tools are built around. It's written in Java, implements the ODK XForms spec, and runs on mobile devices and cloud servers. ✨🏗✨
Other
54
stars
107
forks
source link
Use first repeat instance(s) for jr:choice-name choices #758
What has been done to verify that this works as intended?
Added tests
Why is this the best possible solution? Were any other approaches considered?
My initial instinct was that using a reference to a repeat nodeset rather than a specific repeat instance to specify where choices should be taken from is a form design issue. But then I realized that a standards-compliant XPath engine would use the first repeat instance(s) when given a nodeset reference where it needs a single node reference.
This doesn't work well with choice filters but I think that's ok because it also wouldn't have been possible before. My priority here is to ensure that XLSForms that used to work continue to work without modification.
My recommendation for writing these kinds of choice-name calls would be to make them relative from within the repeat instance rather than making it from outside.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
This only affects choice-name calls given a reference parameter that is a nodeset reference. I think the case in the test is the only one in which this kind of reference would make sense. There's also the analogous nested case and that's why there's a for loop to qualify every unboud reference level.
Do we need any specific form for testing your changes? If so, please attach one.
Closes #757
What has been done to verify that this works as intended?
Added tests
Why is this the best possible solution? Were any other approaches considered?
My initial instinct was that using a reference to a repeat nodeset rather than a specific repeat instance to specify where choices should be taken from is a form design issue. But then I realized that a standards-compliant XPath engine would use the first repeat instance(s) when given a nodeset reference where it needs a single node reference.
This doesn't work well with choice filters but I think that's ok because it also wouldn't have been possible before. My priority here is to ensure that XLSForms that used to work continue to work without modification.
My recommendation for writing these kinds of
choice-namecalls would be to make them relative from within the repeat instance rather than making it from outside.How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
This only affects
choice-namecalls given a reference parameter that is a nodeset reference. I think the case in the test is the only one in which this kind of reference would make sense. There's also the analogous nested case and that's why there's a for loop to qualify every unboud reference level.Do we need any specific form for testing your changes? If so, please attach one.
https://docs.google.com/spreadsheets/d/1MZvF9ynsOdGMWeZF8YsjuoUK9E0t83LZMi5-RsBOEiI/edit#gid=1068911091
Does this change require updates to documentation? If so, please file an issue here and include the link below.
No.