V8: Checkboxlist, radiobuttonlist and dropdown should store a defined data-value not its names

[nielslyngsoe]

I would like Checkbox-list, Radiobutton-list and Dropdown to have the ability to define a data-value, which ´if defined´ will be the stored value instead of the name-value.

Today these data-types only takes one value pr. entry. (which is both the display-label and the data-value)

I would like each entry to have a display-name/label and the option for a data/value.

I have multiple reasons for this, but the main reason is that its makes sense to have control over what gets outputtet in the template, while begin free to write a label that makes sense for the editor.

Offen the output of such data-type is used to set how things should work, lets say we have a few align options, like these: ["left", "middle", "right"]. After sometime the client say they dont understand "middle", and if we could rename it to "center (preferred option)". With the current solution that would be a mess cause then we would also have to adapt our template code to work with "center (preferred option)" instead of "middle".

Let me know if I need to specify the need for this even further.

[bjarnef]

@nielslyngsoe it would be great if the e.g. the checkboxlist and radiobuttonlist are using "label" and "value" similar to when adding prevalues to e.g. settings/styles in Grid using radiobuttonlist and colorpicker (unfortunately there isn't an checkboxlist prevalue editor), but I think it should be added, see this this old PR https://github.com/umbraco/Umbraco-CMS/pull/1496 where it add a checkboxlist prevalue editor).

[zpqrtbnk]

A bit of history: in the past, we had some data editors that would support storing the ID in the value, while displaying the labels in the lists (dropdown, etc). But, this meant that rendering the labels on a page was expensive, because one had to fetch the labels corresponding to the IDs, and accessing datatype configuration (formerly known as "prevalues") was cumbersome and slow.

Ah, and we had some tricks in place, because the Xml cache needed to display the labels, not the IDs, too.

And somehow, to get rid of this mess, we got rid of the ID-storing and went for labels.

Now, it would totally make sense to want to show labels having nothing to do with IDs. Especially in multilingual environments. And, dealing with datatype configuration is now fast and cheap. So, we could totally store IDs only and populate the labels in property value converters, if needed.

So... definitively worth investigating.

OTOH - we cannot change the behavior of existing data editors - at least not change the default one.

[PerplexDaniel]

Agree that it would be a great change to let the developers specify label/value for checkbox / radio / dropdown lists rather than just the label which then gets some random pre-value. Thanks Stephan for the background on why that is.

We actually never use these built-in types for exactly this reason and are using custom versions with label/value for years now. The ModelsBuilder class then has the selected string value (dropdownlist/radiobuttonlist) or selected IEnumerable<string> values for checkboxlist. That's the only thing actually stored with the content. Other labels/values just come from datatype config.

It's great for mapping let's say an Enum in C# to some dropdown list in Umbraco with human readable labels and the Enum.ToString() as values.

[umbrabot]

Hiya @nielslyngsoe,

Just wanted to let you know that we noticed that this issue got a bit stale and might not be relevant any more.

We will close this issue for now but we're happy to open it up again if you think it's still relevant (for example: it's a feature request that's not yet implemented, or it's a bug that's not yet been fixed).

To open it this issue up again, you can write @umbrabot still relevant in a new comment as the first line. It would be super helpful for us if on the next line you could let us know why you think it's still relevant.

For example:

@umbrabot still relevant This bug can still be reproduced in version x.y.z

This will reopen the issue in the next few hours.

Thanks, from your friendly Umbraco GitHub bot :robot: :slightly_smiling_face: