Implement Compound Fields only for is_list #1071
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
📒 Description
A follow up on #1065.
CompoundFields currently aggregate choices, but the description mentions "repeatable fields". Which allows it to render a choice item in the found order. In the regular case where an object has two fields, and either one of those fields must be set (or read) I would prefer to access that field by its field name, not field1_field2 or choice. There is only one situation - I am aware of - where I want to maintain order: this is when the choice field is part of a sequence with maxOccurs > 1, hence it becomes a List.
Resolves #1070.
🔗 What I've Done
At the compound field generation stage, explicitly check if any of the grouped attrs is in fact a list. In otherwise we assume that it is not.
💬 Comments
Now there must likely be a situation where this approach fails. And I wonder how the generation 'compound-fields' handles multiple elements, where only one is allowed. But this would be an issue for the existing code too.
🛫 Checklist