Hi,
Okay, that makes sense - there's probably no reason to allow more than one
hook to override the output. The one downside of this approach that I can
see is that functions that don't override the output might not get called at
all, if they're later in the array than a function that does override it. I
don't think that's a big deal, since I can't imagine some large amount of
custom code called for every broken link, or two extensions "collaborating"
on creating a new link. Unless anyone objects, I'll go with your suggestion.
-Yaron
On Wed, Mar 5, 2008 at 12:02 PM, Simetrical <Simetrical+wikilist(a)gmail.com>
wrote:
On Wed, Mar 5, 2008 at 11:49 AM, Yaron Koren
<yaron57(a)gmail.com> wrote:
The idea of having it at the top of the
function, and making it more
comprehensive, makes sense; but I don't understand the specific code
you
suggested. My understanding is that wfRunHooks()
normally returns true;
in
that case, if the call is placed at the top of
the function, whatever
value
the hooks set the broken link to will get
overridden by
makeBrokenLinkObj()
itself. Or is the idea that every function that
uses this hook should
return
false, thus ensuring that no more than one
function is called for it?
The idea is that functions could do two things:
1) Override the output entirely, by setting $ret and returning false.
2) Modify the function's parameters, and return true.
I'm not sure how much more flexibility is reasonably possible. It
doesn't seem like it would make much sense for multiple extensions to
modify the appearance of broken links in really arbitrary ways. What
would you suggest? The hook could be near the bottom instead, right
before the definition of $s, with lots more parameters. By that
point, some of the original parameters (like $text) have been
overridden, but that could be changed.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l