On 16/03/11 10:38, Jeroen De Dauw wrote: > 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" :)
With these explanations I now understand more clearly what we would do. Basically, the first step would be to make object-based parameter declarations to replace the current ones in result printers, and to use these for validating inputs (and for recording errors, i.e. we would still use SMW's error reporting mechanisms). If we want to introduce a dependency to Validator, then SMW 1.6.0 would be a good opportunity to do it. Would you be willing to implement these basic changes in SMW and SRF? This would then need to be ready by late April. The above is probably rather straightforward (at least for you), but the quest of having components report their input parameters leaves some more tricky architectural questions, in particular since it is not always that clear which component is "responsible" for a parameter. Examples: * "limit" is a parameter that is introduced and used by the query parser, not by any result printer. So it seems wrong if the result printers report this as "their" parameter. * Parameters for individual printouts are used in various places by different parts of the code. Which parameters are valid may depend on the type of printout and (if it is a printout for a property) on the datatype of the property. It probably makes sense to assume that the user of such parameters (e.g. Special:Ask) is always aware of the general logical structure (which components govern which parameters) and only uses the facility to get a list of relevant parameters (without any "logic" attached to it). Still not completely obvious. Regards, Markus ------------------------------------------------------------------------------ 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
