Skip to content
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

Closed
lognaturel opened this issue Apr 4, 2022 · 2 comments
Closed

Always generate secondary instance for selects #603

lognaturel opened this issue Apr 4, 2022 · 2 comments
Assignees
Labels
Milestone

Comments

@lognaturel
Copy link
Contributor

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.
  • adding extra choices to a select with the 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?

@lognaturel
Copy link
Contributor Author

@lindsay-stevens You up for taking this on soon? Let me know if you want to discuss before diving in.

@lindsay-stevens
Copy link
Contributor

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. builder_tests.py. Others using assertPyxformXform are being refactored from xml__contains to xml__xpath_match as part of fixing them, which sometimes takes a bit of git archaeology if the test intent isn't obvious.

lindsay-stevens added a commit to lindsay-stevens/pyxform that referenced this issue Jul 21, 2022
- 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.
lindsay-stevens added a commit to lindsay-stevens/pyxform that referenced this issue Apr 20, 2023
- 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.
lindsay-stevens added a commit to lindsay-stevens/pyxform that referenced this issue May 5, 2023
- 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants