Hey,
> Is it worth giving it another chance at the MediaWiki "Hackathon" in
Berlin in May, though, assuming you're going to that? Perhaps in person
people will be less likely to just ignore the issue? It's only two months
away, so maybe it's worth waiting.
I'm going yes, but am not to positive about people having a different
attitude there. In any case, the only real drawback I see to making SMW use
Validator at this point, and then have it in MW core later on, is the small
effort you need to avoid loading the copy SMW has when MW is already loading
it. Also, unless you want a new SMW to become dependent on MW 1.18 (or
whatever version Validator gets in), you'll need an included copy anyway.
> I do not quite understand how Validator groups parameters, or how it
associates parameters with parser functions (does it?).
Not really, although it provides an utility class to make parser hooks that
use the other Validator functionality out of the box, but there are (parser
related) issues with it, so I suggest not using it for SMW.
> In our case, we have multiple parser functions (#ask, #show) that refer to
the query printers, but the expected parameters are defined by the printers,
not by the parser function.
The core validator class really does not care about the context, and just
needs an associative array with the user-provided parameters and an array
with your parameter definitions. See [0]. The methods returning the
parameter definitions would be the same ones that are already returning the
current array-based definitions. Actual handling of the parameters (with
code similar to the linked example) would happen in the base query printer
class.
> On what level would something like documentation generation then happen
(as we cannot generate a single canonical documentation for #ask)?
Currently the documentation generating code (which is actually a parser hook
provided by Validator) only handles parser hooks implemented via the earlier
mentioned utility class. It's not clear to me how this parser hook can
nicely handle everything defining parameters, as it needs to know how to
access the code, and in case of SMW and Maps needs to be able to handle
parameters getting added depending on the value of another parameter (format
and service, respectively). In any case, the documentation generation is
actually a good example of functionality made possible by having these kinds
of parameter definitions which I did not think of until after writing
Validator. This was when I was writing SubPageList, and started on the docs,
and thought "well, this info is already in the extension, if only I could
get it out" :)
[0]
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Extension:Validator#The_Validator_class
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
------------------------------------------------------------------------------
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
