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 8 commits into
base: master
Choose a base branch
from

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" }
  ]  
}

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.

obj.val = obj.val.split(separator);
}
obj.isVisible = true;
obj.elId = `input-${obj.name}`;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not related tables proof. Id should be truly unique, e.g. by including layer name like in the else clause:
obj.elId = `input-${currentLayer}-${obj.name}`;
Not sure why same code is in several if:s though. maybe my fault.

@steff-o
Copy link
Contributor

steff-o commented Dec 6, 2024

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

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