Show error for attempts to use ${} name values in choices sheet.

[MartijnR]

Update: only the name column is relevant in this screenshot

[MartijnR]

Or is there some accidental ODK Collect feature that evaluates ${}? https://forum.opendatakit.org/t/dynamic-choice-list/22903/9 Clarified by @lognaturel that the ${node} references never worked in Collect either. It was a change in pyxform that caused this confusion.

[MartijnR]

Error would be better

[lognaturel]

I tried this a while ago in Enketo and it works on some level but doesn't dynamically update. I can't remember the details but I think it's something like it's always one refresh cycle behind as the repeat count is updated.

For reference, people do this because they don't have XLSForm access to specifying a select from a repeat nodeset: #38.

[MartijnR]

In this case the XForm output contains ${references}, and those would not be resolved in Enketo.

[lognaturel]

In this case the XForm output contains ${references}

That's if there are no translations for the form. It used to be that pyxform generated an itext block and pulled all strings out no matter what. pyxform v1 changed that so itext is only generated if needed. That's what I explained on the forum and why this structure stopped working for some folks.

[MartijnR]

Oh ok, thanks for clarifying. I missed that. One day I should figure out what is not working in Enketo and create a bug report.

[pbowen-oc]

Hi @lognaturel & @MartijnR -
We do not use references in choice names, but we do use them in choice labels to make pseudo-dynamic choice lists. This currently works for us with the minor exception that Pyxform forces us to have some static text in the label even if want it to be solely an item reference.

We also have cases where we just want to show item text as part of a label to help a user answer questions.

Here is an example with both cases of dynamic choice label text:
dynamic label test_minimal.xlsx

[lognaturel]

Thanks for sharing, @pbowen-oc. The behavior hasn't changed for any of these examples because they all use static choice lists. output inside of labels for those have always been unambiguously supported as far as I know. It would be good to add tests, though.

I think the weirdness comes in when there are secondary instances/dynamic choice lists. @MartijnR should output be allowed and generated by pyxform for those labels? I did some quick exploration and there's something really odd going on. Seems that on XLSForm Online translations are not generated for secondary instances if there's only a single language. Seems right to me but it breaks this type of form with a secondary instance because pyxform doesn't expand the ${} references to XPath paths in outputs.

However, I can't seem to reproduce this at the command line with pyxform v1.0.0, v1.1.0 or master. There, I get generated translations with outputs and expanded XPath paths (doesn't seem ideal but does make the original form from the issue work). I wonder whether it could somehow be related to Python version or something crazy like that?

I don't have time to dig in deeply now so I propose we do a release sooner than later and right after the release compare the behavior in XLSForm Online and pyxform to see whether we still have a problem or not.

[MartijnR]

@lognaturel, sorry for not responding. After posting #515, which appeared to be a duplicate of what you reported above, I propose we deal with <output> there, and focus this issue on using ${node} in the name column only.

[lognaturel]

Here's a user trying to use this kind of reference in an additional data column. Ideally we'd also detect and fail on that.