Dantman wrote:
I don't get how settings would be done using OOP instead of global settings in variables. If that's the case has anyone ever considered some type of Settings class which instead of using PHP variables parses a Settings file?
I think that's what Mediawiki class (Wiki.php), in part, should be for. It should create the wiki environment when it runs. (as an aside, the internal documentation in Wiki.php describes it as the "base" class. I think this is an inadvertent misuse of the term - it should be the core of the wiki, but not necessarily a base class for anything else).
One of the bits missing from using Wiki.php in a very general way is persistance. A settings file (or a database table(s)) can provide this. If wiki settings were handled with a special page too, then moving settings into a db table(s) would be a good thing. LocalSettings.php could be eliminated entirely. A setting file to save DB access info will always be required, I guess. But I digress...
Because even though this can be used to setup and install things, it's still possible for someone to manually edit the .ext/.enable and other configuration stuff to configure it without the manager.
The more manual intervention, the more possibility for things to get mucked up. I think it would be best to get rid of this sort of thing rather than make it the centre of all things. At the start, manual intervention is required, but a future version (MW 2.0?) should eliminate it wherever possible.
What do you think the ExtensionManager should delegate to the class?
A class delegates whatever it doesn't directly control. An extension should only know about itself and how to handle its responsibilities in the wiki. That doesn't mean that the extension should know how to install itself. Installation should be in the extension manager and the extension only knows how to ask the manager to install it and supply the data to the manager.
require_once( "extensions/Something.php" )
This can be taken out of LocalSettings and put into Wiki.php with some clever coding. The most basic info required from the user is information on where the wiki is locally installed - $IP, $wgScriptPath, that sort of thing. Once these things are known, all the other stuff can be generated for a "normal" installation.
I don't think ExtensionManager should delegate settings to the extension though.
I agree - the specific example of delegation I mentioned - $wghooks - would be to another class. A quick look at the code shows that Hooks.php is a candidate (though that is a function, not a class - this is easy to change).
One thing about converting from a lot of globals to members of a class - if the first step puts the globals into various class files and keeps them public (not as true memebers of the class), the existing code should work without change. As a specific global is removed from all existing code and replaced with accesses to the relevent class, it can be moved from a globally accessible variable in a class's php file to a private data member.
Mike