I've made some changes promoting better coding patterns in some contexts.

These are for MediaWiki 1.18, extensions can keep their old patterns 
till they drop support for pre-1.18.
I'd like to consider dropping the rewriting of $wgTitle and $wgOut 
inside of SpecialPage::capturePath around MediaWiki 1.20. This means 
that after that release includable special pages in extensions will have 
to use the new patterns instead of relying on the $wg replacement hack.

When working on special pages (ESPECIALLY includable special pages):
- Use $this->getOutput() instead of the $wgOut global.
- Use $this->getUser() instead of the $wgUser global.
- Use $this->getSkin() instead of using $wgUser->getSkin();

In contexts where you are working with $wgOut or another OutputPage 
instance and using $wgUser and skin instances fetched from it to render 
stuff being passed back to output:
- Use $out->getUser() instead of the $wgUser gobal.
- Use $out->getSkin() instead of using $wgUser->getSkin();





---- Extra stuff ----

I have some thought to go through on what to do about the Linker in some 
contexts, but I have some plans I'm thinking of regarding Skin:
- I'm thinking of making $out->getSkin(); the primary point for getting 
a skin instead of $wgUser->getSkin(); (I'll still keep BC), making 
OutputPage the focal point for things related to the output of the page. 
Having OutputPage track and manage skins also avoids some special case 
bugs, it's actually more sane for OutputPage to manage the skin when you 
examine various branches of code.
- Along with making OutputPage track the skin I'm planning on dropping 
support for getSkin( $t ); examining the code it's not actually even 
used, and the only code using it actually shouldn't be playing with a 
full skin at all anyways, and making Skin defer to OutputPage for most 
of it's title information. Instead of having 3 near-global copies of the 
Title floating around ($wgTitle, $wgOut->mTitle, 
$wgUser->getSkin()->mTitle).

I haven't decided what do about the linker yet. But I'm considering 
making the Parser get it's linker via $po->getLinker(); (either 
ParserOutput or ParserOptions, I need another look) and getting a plain 
linker instance instead of a skin. Skin will define a getLinker() which 
will replace it's subclassing of Linker (there will be some bc). To 
allow for the overloading of parts of the linker, which was sorta 
possible already, but making it more reliable, getLinker would be 
overridable by a skin that wanted to make linker changes so it could 
return a subclass of the linker. The getLinker in Parser context will 
take that into account, if a subclass of Linker is being used instead of 
the normal linker the parsercache key will change, as a result we will 
both make overriding linker methods reliable and usable, while also 
avoiding any unnecessary parser cache fragmentation which would happen 
if we went and included the skin name into the pcache key.

-- 
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to