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.