Thanks for pointing this out; I'll fix it soonish. Please post such issues on the extensions discussion page or bugzilla. They have nothing to do with the Subject of this thread.
Send from my Android phone. On 30 Jan 2011 01:30, "Daniel Friesen" <[email protected]> wrote: > While reviewing SubPageList to see if it was good enough quality to > install on a wiki of mine, I came round to Validator double checking it > (since SubPageList uses Validator). > > From the looks of the code, Validator, and various Validator based > extensions appear to be using parser->parse() inside of hooks where they > are supposed to be using ->recursiveTagParse with a proper frame. The > Validator extension's api appears to provoke this bad practice because I > don't see the frame in the arguments render methods are using. > > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] > > On 11-01-11 04:23 PM, Platonides wrote: >> Well, I just had an issue with Validator, so I am not too sympatatic >> with your extension right now ;) >> After grepping for setHook, it turns out that an extension like Maps, >> that has zero matches, sets parser hooks indirectly via Validator >> extension. And not only that, but it also sets a hook for a different >> name. It seems to set a hook for<display_map> but actually sets it for >> <display map> (Why??) so that even looking for the full tag name doesn't >> give you any result. >> >> It makes things more complex. On the maps case, the parameters need a >> deal more validation, but for most cases $parser->setHook() is clearer >> than registering a hook to class::staticInit() for a class which extends >> ParserHook and has some functions returning the hook configuration. > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
