-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always generate secondary instance for selects #603
Comments
@lindsay-stevens You up for taking this on soon? Let me know if you want to discuss before diving in. |
This is in progress. It'll be a big PR because the initial change (i.e. ignoring cases requiring static for now) causes ~30 tests to fail. For some of the tests I'm doing a quick-fix on, such as those testing internals e.g. |
- The test was broken by changes to choices processing (XLSForm#603). - The test conditions seem to relate only to the instance_xmlns feature. - The new test asserts the same using the pyxformtestcase pattern.
- The test was broken by changes to choices processing (XLSForm#603). - The test conditions seem to relate only to the instance_xmlns feature. - The new test asserts the same using the pyxformtestcase pattern.
- The test was broken by changes to choices processing (XLSForm#603). - The test conditions seem to relate only to the instance_xmlns feature. - The new test asserts the same using the pyxformtestcase pattern.
Software and hardware versions
pyxform v1.9.0
We've had various conversations about selects and when they're generated as inline/static or as secondary instances/dynamic starting with #203. There are various issues around them such as #387 (comment) and #590
In #590 we are coming to the conclusion that it'd be better to always generate secondary instances and use itemsets.
I believe there are currently two cases that require inline/static choices:
or_other
-- what's the current behavior with a localized form? Maybe we could inject a choice into a secondary instance instead? The ultimate goal is to deprecate this functionality: Add support for translating or_other? #218 (comment) so I think we should preserve it in whatever way is easiest.search()
appearance. I don't remember the details of how this works but I think Collect might need static choices for that (I will check and update)Any other cases that might be special or need static selects?
The text was updated successfully, but these errors were encountered: