-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Dynamic options for checkbox/radio/selector #303
Conversation
I've created this as a draft so I can ask for feedback on the idea in principle before I attempt to add the "delimited" format that I've mentioned in #289. |
Jest Coverage
|
optionsList.push(...generateBVOptions(propertyValue)); | ||
} else if (option !== null && typeof option !== "undefined") { | ||
// single option | ||
if (typeof option === 'string') { |
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.
Technically this bit also allows the list-of-strings format within the project configuration directly, i.e.
{"type":"checkbox", "name":"foo", "options":["option 1", "option 2"]}
but this should be rejected by the schema-driven JSON editor.
A note from our recent discussion, from my understanding the behaviour of
if
|
Yes, the first three (dict, array-of-object, array-of-string) already work, the single string with delimiters is still to be implemented. |
Not sure what the default combination of separators & delimiters makes the most sense though. Should we be detecting only delimiters Thinking about it, I'd imagine in most cases people would want to do the second case more often? |
41f7981
to
6908191
Compare
I've implemented the delimited string option now, with the default delimiters being
The between-options delimiter can be overridden by specifying {"fromDocument": "options", "separator": "~~", "valueLabelSeparator": "::"}
(Note I've also made it |
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.
I've tried this out and it's working for me!
Can you add an example document.json and project configuration.json to the examples
folder?
Here's an example of one I made to test the feature based on your documentation:
[
{
"id": "1",
"text": "Testing options specified with array of dictionary",
"options": [
{"value": "val1","label": "Object label 1"},
{"value": "val2","label": "Object label 2"},
{"value": "val3","label": "Object label 3"}
]
},
{
"id": "2",
"text": "Testing options specified with array of dictionary",
"options": {
"val1": "Key value label 1",
"val2": "Key value label 2",
"val3": "Key value label 3"
}
},
{
"id": "3",
"text": "Testing options specified with array of string",
"options": [
"String array label 1", "String array label 2", "String array label 3"
]
},
{
"id": "4",
"text": "Testing options specified with a single string, separated using special characters (= and ; by default)",
"options": "val1=Separator label 1;val2=Separator label 2;val3=Separator label 3"
},
{
"id": "5",
"text": "Testing options specified with a custom separator (:: and ~~ in this case)",
"options": "val1::Custom separator label 1~~val2::Custom separator label 2~~val3::Custom separator label 3"
}
]
The structured array or object forms of fromDocument options work well when documents are supplied in JSON but are tricky to map effectively when uploading documents as CSV. We now also support the case where the property pointed to by fromDocument is a single string. By default this is assumed to be a semicolon-separated list of options, where each option is of the form value=label, i.e. {"options":"orange=Orange; kiwi=Kiwi fruit"} is treated as if it were {"options":[ {"value": "orange", "label": "Orange}, {"value": "kiwi", "label": "Kiwi fruit"} ]} The ';' and '=' separators are configurable by properties alongside the "fromDocument", and can be any string (not just single characters), e.g. {"fromDocument": "options", "separator":"##", "valueLabelSeparator": ":"} with document {"options":"option1: Option 1##option2: Option 2"}
- project config that has a radio button with a "fromDocument" declaration plus one static option - a set of four sample documents that each defines three dynamic options in one of the valid formats - array of {value/label} objects - plain dictionary - array of strings - single string with val1=Label1;val2=Label2 and a test that verifies that all four documents render four options each (the three from the document plus the one from the config)
…docs, apart from the one section where we introduce the dict format as an alternative.
…ks in plain text documents.
d737e67
to
b093f40
Compare
I've added the examples you requested, and also improved the documentation more generally so we consistently use the array style (that preserves order) rather than dict style (that doesn't) for all checkbox & radio samples except the section that specifically introduces the dict style as an alternative. |
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.
Looks good to me!
Implementing a mechanism to take checkbox/radio/selector options from the document as well as from the static project configuration, to allow for things like entity disambiguation tasks where the list of possible options varies from document to document.
The initial implementation is based on a new type of entry in the
options
array, so as well aswe now support
which in turn expects
someProperty
in the document JSON to have the same form as the originaloptions
configuration itself (either an array ofvalue
/label
objects, or a dictionary mapping values to labels). For convenience I've also added support for an array of plain strings, where a string"X"
is treated as if it were{"value": "X", "label": "X"}
.Closes #289