Controlled Vocabulary Select List Widget

[patdunlavey]

We need a webform widget for controlled vocabularies that works like a standard select list. The list of select options set through webform configuration or a webform options configuration yml file. However, rather than "label" and "value", each option will include controlled vocabulary fields: label, authorityUri and description. When submitted, all three values are saved into the strawberryfield json (and the webform submission when the submission is configured to be saved).

[patdunlavey]

@DiegoPino - comments?

[DiegoPino]

@patdunlavey thanks! Question: Description. Do you need that in the metadata? Will people search for that/facet? All the rest sounds good, I just will just suggest we normalize the authorityUri for value to be JSON-LD compliant and because it makes filtering easier (because all other LoD elements also use value) but open to discuss/ be fight back on this. Give me a day to prepare a simple to follow roadmap on this, the solution seems simple enough to get it rolling as a single commit to the RC2 branch.

[patdunlavey]

@DiegoPino My thinking was that the description might be desired for display - for example when displaying the term, a tooltip might show the description of that term (just as the term may be rendered as a link to the uri). However is is not in any requirement that I know about and can probably be left out. If we do that, it seems to me that we can avoid the need for a complex form element, since the label/value pair can be managed in a single select element. If we do that, then we can also change authorityUri to value, since we will not need to track two values - description and auhorityUri. Thanks for offering to sketch out a roadmap for this. Any training wheels are very much appreciated!

[DiegoPino]

@patdunlavey for that use case we can use a hidden feature of the Metadata Display entity. Since it is "field-able" each Twig template can have an extra SBF attached and that one can be used for EXTRA data (static, mappings, descriptions, lists of arguments you do not want to put in the Metadata/JSON but you may want for description purposes). We already use that for a Finding AID project where a lot of the language ISO encodings needed extra info that had no place in the JSON.

[DiegoPino]

@patdunlavey a few updates:

I'm digesting now a few approaches but one that is winning over the others is this one and I will share code by Monday (or the weekend if I code fast) so you can go and refine it later.

1.- Having a compound element is tricky here because we may want to allow multiple selections in the select. Compounds allow that by adding a + and - sign to a table like display. That is good if you want to allow, e.g a certain limit of selections but, has the issue that each element becomes independent, means users (and may happen) could select the same twice. Solution: Make it a simple select box that on the value callback is able to read an array or objects, same as Wikidata but in this case we have to code it ourselves instead of depending on Webform Element Compound element to do that for us. All the rest of the operations will be the same as for any select, but in the element validator we will set values back as arrays of objects (pairs) back into the webform element.

This solution has a few extra benefits. The element will be also be able to read normal values (just an array of values) but will then convert them into a pair on persistence, which would allow, e.g, not reconciliated, only value ingests via API to be converted to your vocabulary on edit. This of course works only on a one by one Digital Object (for now)

Extra functionality (not for Monday but for next week)

A new Strawberryfield JSON key value plugin, that for given array of values, can apply a mapping function (e.g coming from a webform Option config, or a Taxonomy or an entity and convert it to another array.

E.g Source data

{
"my_terms": ["a","b","c"]
}

procesor accepts a certain mapping config (lets say a webform Config) where 'a' maps to => 'a thing' and 'b'=> 'another thing' and no 'c' but a default option like 'every other thing'

Output

{
"my_terms": ["a thing","another thing","every other thing"]
}

And that is what goes into Solr.

I see a multitude of uses for this. Anyway. To code now. Good weekend

[patdunlavey]

@DiegoPino I'm excited that you are running with this! I agree that for the UI, a standard select list form element would be far superior to a multi-field element - for all the reasons you described. Do I understand correctly that implementing a form validation function is simply Drupal 8+'s hacky way of altering form elements and values prior to processing the form submission, just as we have been doing for years in D7? In this case, it would be to inject the key/value pair into the submission so that it could be processed/persisted as if the user had selected the term name and its corresponding uri in separate field elements? I really like your Strawberryfield JSON key/value plugin idea, with pluggable mapping sources (webform options, taxonomy, etc). That's a wish-list item for another day, correct? Anyway, thanks again for kick-starting this - you are so generous with your time! I hope I can provide at least a little useful coding on this, and more and more as my D8 development skills increase.

[DiegoPino]

See #99

[patdunlavey]

After getting much further along in our implementation and understanding how the various moving parts fit together, we no longer have a need for this feature. I recommend we close this issue and the associated pull request.

[DiegoPino]

@patdunlavey thanks. Can you close your own pulls? I will close this one.