Instead of extending the array-based parameter definitions used now, I think it makes a lot of sense to use the Validator extension for that. Originally it also had an array-based approach, but this gets really messy, complex and hard to understand as you add more things to it. Now each parameter is an object that can easily be extended.

Loose from that I think the addition of the parameter definitions in the first place is a very good idea (awesome job Yaron :) that opens up quite some possibilities. They area already used in the Ask UI, but can also be used for validation of parameter values, automatic creation of documentation and feedback to the user when making a query with an invalid value for some parameter. (And probably other things that I can't think of right now.)

Obviously this introduces a dependency and some work to modify the current handling of these parameter definitions (and preserving b/c), but the alternative, as I see it, is really to end up with stuff that's harder to use than it needs to be and that's limiting in what you can do with it.


Jeroen De Dauw
Don't panic. Don't be evil.

On 15 March 2011 18:02, Yaron Koren <yaron@wikiworks.com> wrote:

Right - although "limit=" does get used in regular #ask queries (pretty often, actually), so I think it makes sense to define it as a real parameter with its own input.

The idea of having defined parameters that don't get displayed in the Special:Ask form is an interesting one. I guess the real question is what the values of getParameters() get used for - if it's only to display that Special:Ask form, then having "hidden parameters" might still make sense, but it's not really high-priority. But if getParameters() gets used for anything else, then the idea definitely starts to makes sense.