https://bugzilla.wikimedia.org/show_bug.cgi?id=51375
Krinkle <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|TemplateData: Add parameter |TemplateData: Add parameter |type for selecting one of |type for selecting one of |predefined values |predefined values (like |("enum"-like) |"<select>" or ENUM) --- Comment #6 from Krinkle <[email protected]> --- 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. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
