I've been poking around looking at hooks and ways to tie in new features into Mediawiki via extensions, and it seems like unless a hook happens to be defined where you want it, you have to either add the hook yourself, or instruct the user of your extension to modify their code and call your extension directly.
Both seem sort of messy. Are there any plans to broaden the range of hooks other than by just adding more instances of hooks? What about doing something like tying in hooks to wfProfileIn and wfProfileOut, so hooks could be called before / after all functions are executed? A more involved change would be also to pass the $this and the return value into the hook when calling wfProfileIn and wfProfileOut.
Any ideas?
Travis
On Thu, 2006-10-26 at 11:45 -0400, Travis Derouin wrote:
Both seem sort of messy. Are there any plans to broaden the range of hooks other than by just adding more instances of hooks?
I don't think so. I don't think the idea of modifying the profile stuff is a good idea, since the hooks that work now take (sometimes modifiable) arguments, which don't get passed to the profiling commands.
I'm interested in expanding the scope of hooks, so suggestions for places to put them are very welcome. Are there places that you think there should be hooks, that they don't exist?
Eventually I'd like every "function point" in MediaWiki to be hookable. But collecting the most important actions that require hooks will probably be useful.
--Evan
Yeah, off the top of my head: anything to do with the UI should have a hook, this of course is just coming from my experience with 1.6.7, who knows, there could be tons of hooks in 1.8+. Adding links to the navigation, toolbox, top tabs, etc, the last time I checked this didn't seem possible. It would be great if there was a hook that was called before a page's contents was displayed, and after, so certain pages could be formatted, or enclosed in some HTML, without directly modifying the skin.
Other functionality, like special pages recent changes should have more hooks as well, making it easier to write custom filters for RC, etc. It just seems like continously defining hooks in specific places isn't really sustainable way of allowing developers to build add-ons, and that another approach could be thought out.
Travis
On 10/27/06, Evan Prodromou evan@prodromou.name wrote:
On Thu, 2006-10-26 at 11:45 -0400, Travis Derouin wrote:
Both seem sort of messy. Are there any plans to broaden the range of hooks other than by just adding more instances of hooks?
I don't think so. I don't think the idea of modifying the profile stuff is a good idea, since the hooks that work now take (sometimes modifiable) arguments, which don't get passed to the profiling commands.
I'm interested in expanding the scope of hooks, so suggestions for places to put them are very welcome. Are there places that you think there should be hooks, that they don't exist?
Eventually I'd like every "function point" in MediaWiki to be hookable. But collecting the most important actions that require hooks will probably be useful.
--Evan
Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On Fri, 2006-27-10 at 16:47 -0400, Travis Derouin wrote:
Yeah, off the top of my head: anything to do with the UI should have a hook, this of course is just coming from my experience with 1.6.7, who knows, there could be tons of hooks in 1.8+.
There are!
It just seems like continously defining hooks in specific places isn't really sustainable way of allowing developers to build add-ons, and that another approach could be thought out.
Well, if you run a debugger, you could put breakpoints at any line of code and possibly at arbitrary expressions. It also slows down your code to a crawl, and it gives far more modifiability than anyone really needs.
The chain of responsibility pattern is a classic way to provide run-time modifiable behaviour.
-Evan
There are!
Right, but my point is, this approach doesn't seem to be sustainable, I imagine that it's like documentation - define a new function or piece of code - add a hook later when someone points out one doesn't exist.
Well, if you run a debugger, you could put breakpoints at any line of code and possibly at arbitrary expressions. It also slows down your code to a crawl, and it gives far more modifiability than anyone really needs.
I guess I wasn't too clear. Ideally, an extension should be something that an admin can just unzip, add a line to LocalSettings.php, and boom, it works. About half the extensions I've written, or installed myself, require modifying the actual code base, which makes it a) harder for the end user to configure and b) more of a pain to upgrade to the next version of Mediawiki. If there were a better system in place that really opened up Mediawiki (instead of just definining more hooks), extensions would gel better with the current software, would be more accessible and would have longer longevity.
Of course, I don't have any ideas, other than the not so great idea of tapping into wfProfileIn and wfProfileOut, but it seems that if we call these 2 functions for each function just to profile the software, it would be probably even more useful to use that space to call any available hooks that have been defined for any extensions, it just would seem more applicable.
Travis
Evan Prodromou wrote:
On Thu, 2006-10-26 at 11:45 -0400, Travis Derouin wrote:
Both seem sort of messy. Are there any plans to broaden the range of hooks other than by just adding more instances of hooks?
I don't think so. I don't think the idea of modifying the profile stuff is a good idea, since the hooks that work now take (sometimes modifiable) arguments, which don't get passed to the profiling commands.
I'm interested in expanding the scope of hooks, so suggestions for places to put them are very welcome. Are there places that you think there should be hooks, that they don't exist?
Eventually I'd like every "function point" in MediaWiki to be hookable. But collecting the most important actions that require hooks will probably be useful.
The problem is that MediaWiki changes. If you add more hooks, then more of them will break between versions. As a core developer, I don't want to have to fix dozens of checked-in extensions every time I make a change, or to break all the externally maintained ones. There are "good quality" hooks, which have had the same functionality since hooks were invented, and can be expected to retain that functionality for the forseeable future. And there are bad hooks, which have been broken since the time they were introduced, and will be removed ASAP. You both seem to be suggesting that we should add many more of the latter kind.
If you want to make a change, and you don't mind if it's broken by the next minor release, why not just make a patch? I think I would prefer it if we tried to make hooks a stable extension API rather than the runtime equivalent of a source patch.
-- Tim Starling
wikitech-l@lists.wikimedia.org