Last modified: 2014-07-08 06:31:39 UTC
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.
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.
