Re: [Wikitech-l] Some changes to $wgOut, $wgUser, Skin, and SpecialPage code patterns
On 3 April 2011 09:17, Daniel Friesen wrote: > 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. That's too fast. Needs at least few releases without and with wfDeprecated(); -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Some changes to $wgOut, $wgUser, Skin, and SpecialPage code patterns
On Sat, Apr 2, 2011 at 11:17 PM, Daniel Friesen wrote: > 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. > [snip] > 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(); > Seems like a good direction; this basically is encapsulating some of the 'global state' (which is really "web UI state") into one place, and letting us use a different set of state when appropriate. 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. > I'd be kind of inclined to separate out the Skin and Linker worlds a bit further; really, the HTML formatting of links and such doesn't depend on the user (except in some edge cases like stub links which could in principle be done differently). The surrounding *skin* depends on the user settings, but having to dive into a User object to get a Linker feels messy, especially if we're rendering a wiki page to go into a common cache. IIRC the biggest remaining use case for link rendering actually being customized by skin was for the special skin used for creating static HTML dumps. If we had another way to do that, and normalized stub linking in some way (say, by always sticking a magic class on and letting CSS deal with it) it might be cleaner to avoid having to touch a Skin object unless you're actually doing final HTML output. (This may be a bigger project though. :D) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Some changes to $wgOut, $wgUser, Skin, and SpecialPage code patterns
On 11-04-03 07:29 AM, Niklas Laxström wrote: > On 3 April 2011 09:17, Daniel Friesen wrote: >> 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. > That's too fast. Needs at least few releases without and with wfDeprecated(); > >-Niklas How are we supposed to put wfDeprecated into all calls made to $wgOut and $wgTitle, specifically in the context of a special page? Tbh, most extensions actually won't break when we drop support for that. The only situation where they'll break is if they are an includable special page. And that's two releases they have. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] -- ~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
Re: [Wikitech-l] Some changes to $wgOut, $wgUser, Skin, and SpecialPage code patterns
On 11-04-03 10:28 AM, Brion Vibber wrote: > On Sat, Apr 2, 2011 at 11:17 PM, Daniel Friesen > wrote: >> 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(); >> > Seems like a good direction; this basically is encapsulating some of the > 'global state' (which is really "web UI state") into one place, and letting > us use a different set of state when appropriate. > > 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. >> > I'd be kind of inclined to separate out the Skin and Linker worlds a bit > further; really, the HTML formatting of links and such doesn't depend on the > user (except in some edge cases like stub links which could in principle be > done differently). The surrounding *skin* depends on the user settings, but > having to dive into a User object to get a Linker feels messy, especially if > we're rendering a wiki page to go into a common cache. > > IIRC the biggest remaining use case for link rendering actually being > customized by skin was for the special skin used for creating static HTML > dumps. > > If we had another way to do that, and normalized stub linking in some way > (say, by always sticking a magic class on and letting CSS deal with it) it > might be cleaner to avoid having to touch a Skin object unless you're > actually doing final HTML output. (This may be a bigger project though. :D) > > -- brion I had a short discussion and abandoned the linker as an instance idea. Now the Linker class is intended to be used entirely statically (bc for both Skins and hooks though). I can look into static dumps sometime, I think it needed updates for one of the other skin changes as well. Why did we even pull html dumping out of core? I had some thoughts on offline/static dumping in my skin plans, and it seams to make much more sense for offline support in skins to be built in. ~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
Re: [Wikitech-l] Some changes to $wgOut, $wgUser, Skin, and SpecialPage code patterns
I like it. Specially the Linker change. It really looks the way to have it. > I'm considering > making the Parser get it's linker via $po->getLinker(); (either > ParserOutput or ParserOptions, I need another look) The linker would be an input parameter, so it is a ParserOptions ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Some changes to $wgOut, $wgUser, Skin, and SpecialPage code patterns
On 11-04-04 02:40 PM, Platonides wrote: > I like it. Specially the Linker change. It really looks the way to have it. > >> I'm considering >> making the Parser get it's linker via $po->getLinker(); (either >> ParserOutput or ParserOptions, I need another look) > The linker would be an input parameter, so it is a ParserOptions Yeah, I just couldn't remember which set of code that was when I wrote the e-mail... It's moot now anyways, since Linker is now used statically as Linker::* instead. ~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
Re: [Wikitech-l] Some changes to $wgOut, $wgUser, Skin, and SpecialPage code patterns
I second the idea of the static Linker class. It's far better than the subclass system. Skin modification of links should focus on CSS anyway, rather than trying to overload link generating code. Daniel Friesen-4 wrote: > > On 11-04-04 02:40 PM, Platonides wrote: >> I like it. Specially the Linker change. It really looks the way to have >> it. >> >>> I'm considering >>> making the Parser get it's linker via $po->getLinker(); (either >>> ParserOutput or ParserOptions, I need another look) >> The linker would be an input parameter, so it is a ParserOptions > Yeah, I just couldn't remember which set of code that was when I wrote > the e-mail... > > It's moot now anyways, since Linker is now used statically as Linker::* > instead. > > ~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 > > -- View this message in context: http://old.nabble.com/Some-changes-to-%24wgOut%2C-%24wgUser%2C-Skin%2C-and-SpecialPage-code-patterns-tp31305991p31320028.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Some changes to $wgOut, $wgUser, Skin, and SpecialPage code patterns
Brion Vibber wrote: > I'd be kind of inclined to separate out the Skin and Linker worlds a bit > further; really, the HTML formatting of links and such doesn't depend on the > user (except in some edge cases like stub links which could in principle be > done differently). The surrounding *skin* depends on the user settings, but > having to dive into a User object to get a Linker feels messy, especially if > we're rendering a wiki page to go into a common cache. > > IIRC the biggest remaining use case for link rendering actually being > customized by skin was for the special skin used for creating static HTML > dumps. > > If we had another way to do that, and normalized stub linking in some way > (say, by always sticking a magic class on and letting CSS deal with it) it > might be cleaner to avoid having to touch a Skin object unless you're > actually doing final HTML output. (This may be a bigger project though. :D) I filed two bugs after reading this: * Avoid parser cache fragmentation[1] * Remove stub link formatting user preference from MediaWiki core[2] MZMcBride [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=28424 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=28426 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
