Hey,
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.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
On 15 March 2011 18:02, Yaron Koren <ya...@wikiworks.com> wrote:
> Hi,
>
> 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.
>
> -Yaron
>
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
