"DanTMan" dan_the_man@telus.net wrote in message news:48244173.7020208@telus.net...
Agreed, SpecialPage:setGroup( $pagename, $group ); is not good to use. We used to use SpecialPage:addPage( Object ); to add in new special pages. Except this ends up loading both the SpecialPage class, and the class for the extension. Honestly I'm guilty of still using it because I only recently found out that even before I started using it the thing had been depreciated and the proper way to add a new special page was to add the array with it's class name and constructor to $wgSpecialPages. However, the current setGroup actually just appends to $wgSpecialPageGroups. So we should be treating this in the same way. The SpecialPage addPage and setGroup functions do exist. But they should be both considered depreciated functions there only for compatibility with old extensions and the misinformed. Everyone should be using $wgSpecialPages and $wgSpecialPageGroups in their extensions.
Honestly, now that I think about it anything added to $wgExtensionFunctions probably shouldn't be part of a big class integral to an extension. For cleanest code it should probably still be ok to have a class with the name of the extension and have it contain the various MagicWord hook methods, ExtensionFunctions and such. But leave SpecialPage classes and methods for anything like ParserFunctions in other classes in other files which will only be loaded when and if needed.
[SNIP]
So, is anything going to happen regarding this? The important issue, I think, is to sort out the implementation of the low-level stuff (i.e. how you specify the section that a page goes under) as this will start being used by extensions, and we don't want it to change once it has been officially released.
This needs to be fixed soon, before 1.13 comes out!
As I said, I submitted a patch that works in a slightly different way, and this is in bug 10457, but it needs someone to take a look at it. In my view it is important that it works in a backward-compatible way, so extensions don't have to do version-sniffing in order to know whether they can use this functionality or not. It should also be done in a way that doesn't force classes to be loaded prematurely, and I don't know if my method does that or not.
The rest of your suggestions are generally good, but as they are about the display (output) it is less critical that those kinds of things are resolved speedily.
- Mark Clements (HappyDog)