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@gmail.com wrote:
On Wed, Mar 5, 2008 at 12:33 PM, Yaron Koren yaron57@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l