Page MenuHomePhabricator

TemplateData: Add parameter type for selecting one of predefined values (like "<select>" or ENUM)
Open, HighPublic1 Estimated Story Points

Assigned To
None
Authored By
AzaToth
Jul 15 2013, 5:41 PM
Tokens
"Like" token, awarded by Tkarcher."Like" token, awarded by AntiCompositeNumber."Like" token, awarded by Liuxinyu970226."Burninate" token, awarded by czar."Barnstar" token, awarded by Psychoslave."Orange Medal" token, awarded by Krinkle."Like" token, awarded by FoXFTW."Like" token, awarded by eranroz."Like" token, awarded by Amire80."Like" token, awarded by fbstj."Mountain of Wealth" token, awarded by Ricordisamoa.

Description

Sometimes for templates, you have a pre-defined set of values to use for a parameter. Perhaps it could be a nice thing to expose valid values to the user in a drop down or something.


Version: unspecified
Severity: enhancement

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

See "bug 50760 - Support suggested values" which is quite similar.

https://bugzilla.wikimedia.org/show_bug.cgi?id=50760

Ping @TrevorParscal.

Since wikitext template editing will always be possible, we can't (yet?) enforce values in VisualEditor. We can only suggest.

E.g. if a template parameter "foo" is specified as values: ['a', 'b']. and wikitext has {{echo|foo=x}}, we need to provide a way to edit that, while still being able to set it to a or b.

  • Bug 50760 has been marked as a duplicate of this bug. ***

(In reply to comment #2)

Ping @TrevorParscal.

Since wikitext template editing will always be possible, we can't (yet?)
enforce values in VisualEditor. We can only suggest.

E.g. if a template parameter "foo" is specified as values: ['a', 'b']. and
wikitext has {{echo|foo=x}}, we need to provide a way to edit that, while
still
being able to set it to a or b.

The "normal" way is a drop-down with the target of the drop-down being a free-entry text field that suggests entries (but does not block other entries).

  • Bug 52754 has been marked as a duplicate of this bug. ***

Yeah, we should add this. Though it doesn't have to be as a parameter type. I imagine we could also do it more generically.

params: {
 "key": {
   "type": ...
   "values": [ .. ]

The upside is that this is easier to specify and validate.

An nice bonus is that it would allow one to preserve types regardless of whether the possible values are finite or not (e.g. freeform strings, numbers, dates, page names).

Down side is that it's tricky for consumers like VisualEditor to have a dropdown menu for values that aren't simple strings.

But I think that's fine. Those consumers can choose to support it however they like. E.g. they could support "values" only for string values.

As a nice bonus this would allow VisualEditor to make dedicated select interfaces much better. E.g. a colour picker with limited values could be a row with squares and you visually pick one of those colours (like radio buttons). And a parameter that takes file names (e.g. for icons), could have live previews for the 10 different icons it supports.

The type-restricted implementation would look something like this:

params: {
 "key": {
   "type": "options"
   "values": [ .. ]

And would treat them as type: 'string' with no further type association.

It also has the downside of having a "param" property (values) that only makes sense in combination with another. Making it slightly less intuitive.

params: {

"key": {
  "type": ...
  "values": [ .. ]

Seems a good way of specifying it, +1

Change 263655 had a related patch set uploaded (by Alex Monk):
[WIP] Add a parameter key to limit possible valid values to a given set

https://gerrit.wikimedia.org/r/263655

Krenair moved this task from Next-up to Doing on the TemplateData board.

Change 263655 abandoned by Alex Monk:
[WIP] Add a parameter key to limit possible valid values to a given set

https://gerrit.wikimedia.org/r/263655

Krenair added a subscriber: Krenair.

That's something which would be extremely useful.

I'm currently working on a proposal for ease Wikitionary contribution through templatedata. Such a feature would for example allow to select word category (verb, adjective…).

It would also be useful to be able to use a set of possible values provided by some template/module.

Is this still on the docket? It's vital. Is there some other way of specifying valid string values in TemplateData (TD)? If not, that would appear to be a large oversight if TD is supposed to help users easily interact with template params

Change 263655 restored by Krinkle:
[WIP] Add a parameter key to limit possible valid values to a given set

https://gerrit.wikimedia.org/r/263655

A suggestion from https://www.mediawiki.org/wiki/Topic:Ve06hyihctm4p86n is to allow labels different from the actual value. It can be stored for example with:

"params": {
	"key": {
		"type": ...,
		"values": [
			{"label": ..., "value": ...},
			...
		]
	}
}

Maybe plain strings should also be allowed for convenience, which could be transformed by the extension to

{"label": null, "value": ...}

form. (I’d also suggest to always display the actual value in addition to the label, but that’s up to the consumers, of course.)

			{"label": ..., "value": ...},

where the label should be an InterfaceText (i.e. localizable) or null; like all other InterfaceTexts, plain string input should be accepted and transformed by the extension. The value is a plain string, of course.

thiemowmde added a subscriber: thiemowmde.

This can most certainly be closed via T271825: Add suggested values to TemplateData and the related input in VE (ENUM) . While it's not 100% the same, it should be sufficient to resolve the relevant use case.

If I have a template that accepts three values for foo and renders an error if given anything else, would the user be able to enter a disallowed value using the "suggested values" user interface in such a way that they will not be surprised or dissapointed to see an error in the rendering – after they have saved their changes in the template dialog?

If I understand correctly, the "suggested value" feature is about autocompleting and/or recommending values in a free-form input field, and does not intend to add friction, make impossible, or "power-user only" to enter other free-form values, e.g. a basic HTML select field with no easy way to break out of it, unless the page had a pre-existing unexpected value that VE would need to accomodate for roundtrip. That is what an "options" or "ENUM" feature would be like in the end, I think.

Having said that, implementing suggested values first is fine of course. And depending on the kind of user experience you want to deliver, it might even make sense to provide both of these as part of the same single input type, with a toggleable restriction for free-form values (allowOther: false?). There are many ways to implement these two features differently and I don't think it's obvious that they'll be similar in logic and look, but it is also possible to make them similar/shared. Whether that's the best UX, I don't know. Something to consider I suppose :)