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

feature: multiple choice checkbox in editor #2061

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
Open

Conversation

johnnyblasta
Copy link
Collaborator

Closes #1518
Adds a multiple choice checkbox to the editor with a possibility to have a free text choice.
image

Configurable like this:

{
        "name": "atgardsforslag",
        "title": "Åtgärdsförslag: ",
        "type": "checkbox",
	"options": [
		"Kronhöjning minst >4.6m",
		"Kronhöjning minst >3.2m",
		"Utrymme beskärning ",
		"Borttagnings av döda grenar",
		"Återhamling",
		"Hammling",
		"Leverans högstubbe",
		"Kronretireringbeskärning",
		"Formträdbeskärning",
		"Uppbyggnadsbeskärning",
		"Säkerhetsbeskärning",
		"Avlastbeskärning",
		"Borttagnings av vatten skott",
		"TRAQ 2",
		"TRAQ 3; Klätterandebesiktning",
		"TRAQ 3; Resistograph/tomograph",
		"TRAQ 3; Advencerad Rotbesikning",
		"Annat:textbox"
	]  
}

@steff-o
Copy link
Contributor

steff-o commented Nov 15, 2024

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.

  1. The configuring syntax: it is a bit magic and limits the possible options values. Not that it is likely that someone will have an option that actually contains ":textbox", but still.
  2. While the configuration theoretically supports several "other" options, the implementation only fully supports one. It is possible to add several "other" values, but when re-read only the last is used for all "other" checkboxes.
  3. The configured "other" title ("Annat" in your example) does not enable localization the same way as other controls as it is hardcoded in the configuration.
  4. It is easy to trick the mechanism by using semicolon i an "other" value. If a semicolon is present in the options list it also breaks, but that can be avoided in configuration time, but in "other" fields it should be escaped.

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.

@johnnyblasta
Copy link
Collaborator Author

I think I prefer checkboxgroup if it should be a new input type.
I can take a look at reworking it, so it's less hokus pokus in the implementation.

@johnnyblasta
Copy link
Collaborator Author

  • Introduced a new input type checkboxgroup
  • Changed the configuring syntax, so that it's not magical.
  • Removed the hardcode for separator.
  • Added option for the freetext field so it's not harcoded and makes it possible to add more than one.
  • Added the possibility to have the text and value of the choice to be different.

Example configuration:

{"name": "atgardsforslag",
 "title": "Åtgärdsförslag: ",
 "type": "checkboxgroup",
 "separator": ";",
 "freetextOptionPrefix": "freetext_option:",
 "freetextOptionValueSeparator": "=",
 "options": [
    { "text": "Kronhöjning minst >4.6m", "value": "Kronhöjning minst >4.6m" },
    { "text": "Kronhöjning minst >3.2m", "value": "Kronhöjning minst >3.2m" },
    { "text": "Utrymme beskärning ", "value": "Utrymme beskärning" },
    { "text": "Borttagnings av döda grenar", "value": "Borttagnings av döda grenar" },
    { "text": "Återhamling", "value": "Återhamling" },
    { "text": "Hammling" },
    { "text": "Leverans högstubbe", "value": "Leverans högstubbe" },
    { "text": "Kronretireringbeskärning", "value": "Kronretireringbeskärning" },
    { "text": "Formträdbeskärning", "value": "Formträdbeskärning" },
    { "text": "Uppbyggnadsbeskärning", "value": "Uppbyggnadsbeskärning" },
    { "text": "Säkerhetsbeskärning", "value": "Säkerhetsbeskärning" },
    { "text": "Avlastbeskärning", "value": "Avlastbeskärning", "type": "textbox" },
    { "text": "Borttagnings av vatten skott", "value": "Borttagnings av vatten skott" },
    { "text": "TRAQ 2", "value": "TRAQ 2" },
    { "text": "TRAQ 3; Klätterandebesiktning", "value": "TRAQ 3; Klätterandebesiktning" },
    { "text": "TRAQ 3; Resistograph/tomograph", "value": "TRAQ 3; Resistograph/tomograph" },
    { "text": "TRAQ 3; Advencerad Rotbesikning", "value": "TRAQ 3; Advencerad Rotbesikning" },
    { "text": "Annat", "type": "textbox" }
  ]  
}

steff-o
steff-o previously requested changes Dec 6, 2024
Copy link
Contributor

@steff-o steff-o left a 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.

src/controls/editor/edithandler.js Outdated Show resolved Hide resolved
@steff-o
Copy link
Contributor

steff-o commented Dec 6, 2024

... and tabbing does not highlight the checkboxes ...

@johnnyblasta johnnyblasta dismissed steff-o’s stale review December 6, 2024 15:56

I've made the changes steff-o asked for

@johnnyblasta
Copy link
Collaborator Author

I think I fixed the unique id @steff-o requested, so take a look.
Added highlight for all inputs i form, since all seemed to be missing and also some labelling was missing or incomplete.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Multiple values in editorform
2 participants