Oh, wow - 10 parameters for the hook function? Somehow that seems like
overkill, though I don't know what exactly could be removed from that list.
Would the call to wfRunHooks() be placed before or after the line that sets
the actual link ($s)? If it comes afterwards, passing in the variables of
$style and $inside might not be necessary, since those are just helper
variables that are used to create the link. Maybe it's also better to not
have makeBrokenLinkObj() override the values of $text and $trail, and
instead use new variables for those, so that the original values could be
passed in without problems (and the new variables could similarly be
ignored).
-Yaron
On Wed, Mar 5, 2008 at 12:43 PM, Simetrical <Simetrical+wikilist(a)gmail.com>
wrote:
On Wed, Mar 5, 2008 at 12:33 PM, Yaron Koren
<yaron57(a)gmail.com> wrote:
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.
Putting it at the bottom with more parameters seems like a better
idea, on second thought. I'd still permit hooks to return false and
alter some $ret variable to totally change things if they wanted, but
exposing the parameters $u, $style, $prefix, the modified $text,
$inside, and $trail (as well as $nt, $query, and the unmodified $text,
for reference) could allow some extensions to coexist peacefully. If
there's a conflict there's a conflict, of course, but we may as well
try to avoid that a bit more.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l