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.