Page MenuHomePhabricator

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

Assigned To
Authored By
Jul 15 2013, 5:41 PM
"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.


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

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

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

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

A suggestion from 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 :)

we should distinguish between visualeditor and templatedata.
templatedata provides a syntax to describe the template behavior, and is used not just by visualeditor, but other tools too.

whatever VE decides to do with "illegal" values is an interesting question, but TD itself should allow distinction between "suggested values" and "legal values", because the template syntax itself makes this distinction. VE can ignore this distinction or not, but TD should provide this information.

suggestedvalues serves templates that use {{#switch, and there are several different behaviors when param value is not present as one of the options:

  • the switch may have #default, which does something useful - IOW, an "unsuggested" value is still legal
  • it can have no #default, practically ignoring the value
  • the #default can trigger an error.

TD syntax should allow better description of the behavior, so, e.g., "template linting" tools can detect and flag pages where a template with "suggested values" is used with "unsuggested" value: it can be an error worth flagging (2nd and 3rd cases above, where suggested values really means legal values), and not flag it for parameters whose behavior match the 1st case.

this is not a theoretical/hypothetical issue - such tools exist, and are used on several projects (see, e.g., Module:ParamValidator on hewiki and yiwiki).


Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 12:23 PM