Last modified: 2011-03-13 18:05:20 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 4452 - Adding a "handles" key to hooking code
Adding a "handles" key to hooking code
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-02 19:27 UTC by Jamie Bliss
Modified: 2011-03-13 18:05 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
An implementation based on REL1_6 (2.91 KB, patch)
2006-05-26 15:42 UTC, Jamie Bliss
Details

Description Jamie Bliss 2006-01-02 19:27:49 UTC
The basic idea is in situations where each hook handles a specific item (such as
an action), a hook may tell the hooking code this (by using it as its key in the
$wgHooks[...] array (the array containing the hook functions for a specific
hook; I'll use the term "hook array" when refering to this.) When the hook is
called by the MW code, the caller passes the key (which is derived from the
context, not the hook) to wfRunHooks(). wfRunHooks() checks the hook array for
this key, and (if found) runs that hook before others.

The primary reason for this would be a performance boost in situations where
this is applicable. If the hook function returned false, then only one hook was
called.

Currently, the only hook that this is really useful on is 'UnknownAction', where
the action would be the key. (Since each hook likely handles a specific action,
hardcoded.)
Comment 1 Ævar Arnfjörð Bjarmason 2006-01-02 19:42:54 UTC
So basically you want to add a value that'll be passed via $wgHooks that adds a
priority to hooks, which you could do now by making sure the require's are in
the right order?
Comment 2 Jamie Bliss 2006-01-02 20:04:34 UTC
(In reply to comment #1)
> So basically you want to add a value that'll be passed via $wgHooks that adds a
> priority to hooks, which you could do now by making sure the require's are in
> the right order?

Not exactly. It isn't a priority like 1-10. It's more like the hook is
advertising to the hook code (wfRunHooks()) that it handles a specific item.

It's useful when each hook handles a specific situation (eg, when the action is
"egged"), and all the hooks are using the same variable. (eg, most of the
'UnknownAction' hooks check $action for their action.)

Going with 'UnknownAction' action example, say you have 2 hooks, one that
handles the "go" action, another that handles the "stop" action. You're hook
array may look like this:
 $wgHooks['UnknownAction'] = array( 'go' => 'wfHandleGo', 'stop' =>
'wfHandleStop' );

By the current system, one of them will be called every time (wfHandleGo). If
this bug was implemented, wfRunHooks() would check for the action as a key in
the array first, and (if it was 'go' or 'stop') call the appropriate hook before
the other. Note that if the hook did not handle the action (it returned true),
then the other hook would still be called.

This would only change the order the hooks are called. It does not prevent hooks
from being called or prevent more complex checking in the hook.

This "key" would be optional for code calling wfRunHooks(). If the key is not
passed, none of this is done.
Comment 3 Brion Vibber 2006-01-04 00:00:03 UTC
I'm not sure this is necessary.

UnknownAction is not exactly performance-intensive; it's only going to be called for 
the extra actions (rare code path), and if it has to make a few string comparisons 
before hitting the right one, that's unlikely to be much slower than an array 
lookup.

It would probably make sense to replace UnknownAction with a key string => callback 
registration, though, and use that for the built-in actions as well.
Comment 4 Jamie Bliss 2006-01-04 06:44:20 UTC
(In reply to comment #3)
> UnknownAction is not exactly performance-intensive; it's only going to be
called for 
> the extra actions (rare code path), and if it has to make a few string
comparisons 
> before hitting the right one, that's unlikely to be much slower than an array 
> lookup.

No. But it's the only official hook that could use this. I thought of it while
thinking about bug 4294, which would be called much more often.

> It would probably make sense to replace UnknownAction with a key string =>
callback 
> registration, though, and use that for the built-in actions as well.

I did that with the variable extensions (bug 3420), but someone had said I
should use the hooking system instead.
Comment 5 Brion Vibber 2006-01-04 12:34:40 UTC
Bug 4294 and bug 3420 are also cases where registration by requested type is what
would make sense. $wgHooks provides filter chains, which don't really seem
appropriate for these.
Comment 6 Jamie Bliss 2006-05-26 14:53:59 UTC
Bug 6095 can make use of this as well.
Comment 7 Jamie Bliss 2006-05-26 15:42:57 UTC
Created attachment 1829 [details]
An implementation based on REL1_6

Adds a new function, wfCallHook(), which behaves similarly to wfRunHooks(), but
will only call the specified hook. It's implemented almost identically to
wfRunHooks() as well.
Comment 8 Jamie Bliss 2007-04-06 18:14:25 UTC
Is it safe to close this bug as WONTFIX, in favor of hook-specific functions?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links