-
Notifications
You must be signed in to change notification settings - Fork 55
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
feature: multiple choice checkbox in editor #2061
base: master
Are you sure you want to change the base?
Conversation
Even most of the stuff works as expected I'm not convinced. I don't think that it should be called checkbox. It feels more like a new input type like "checkedlistbox" or "checkboxlist" or "checkboxgroup", with possibility to add extra values. Or a more user friendly dropdown/listbox with multi select. A checkbox with a list of options feels kind of awkward to me. But my main concern is about the additional options that the user can add.
My suggestion is to omit the possibility to configure the use of "others" in the options list and instead have a flag in a "config" object that says if it is allowed to add "other" values, and possibly one or many. If many "others" are allowed a new "other" row is created when the one visible is checked. On re-read, all options from database that are not in the options list are added as pre filled "others", or like the regular options. It should also be possible to configure the separator, now hardcoded to semicolon. Other than that, there is a bug when using this feature in related tables as the input fields are not getting unique ids. It is however a result of a bug in the existing code for checkbox that does not include layer name in the id. |
I think I prefer |
Example configuration:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No doubt that this will be a great addition and the text and value approach is a great feature, however it seems like we don't share the same vision when it comes to the "other" values. You may have a stronger case, but here is my take on it:
- It could possibly simplify backend operations if all values including the others are stored in the same way in the database. Your approach is robust when it comes to roundtripping in Origo, but if you want a backend integration it will be necessary to parse the string in the database. If all values where stored using only a separator, any list splitting operation will do. I think it would be possible to implement it in that way if you don't require to match the value against a specific "other" label as described in my previous comment.
- The text property on the "others" is a candidate for localization as a part of the GUI, not a part of the values, which makes me think it should be a localized string in editform. Also if made that way, it won't be necessary to store it in the database which makes previous point easier.
Do what you want with that, but I request a change on the id-creation.
... and tabbing does not highlight the checkboxes ... |
I've made the changes steff-o asked for
I think I fixed the unique id @steff-o requested, so take a look. As for the the other value I think I will leave it as it is for now since it works and is flexible for possible use cases. I see there is possible ways to do this, for one would to save the values as a json object. Yes it could be localized if it only is a others field, but perhaps some will use it more creatively. |
Closes #1518
Adds a multiple choice checkbox to the editor with a possibility to have a free text choice.
Configurable like this: