* Daniel Friesen <li...@nadir-seen-fire.com> [Sun, 17 Apr 2011 10:16:31
-0700]:
> >> Continuing with my changes to $wgOut, $wgUser, Skin, and
SpecialPage
> >> patterns.
> >>
> >> The Linker is now static, $sk->link will still work, however you
> should
> >> not be requiring a Skin anymore to use linker methods. Please use
> >> Linker::link directly.
> >> The only exception is the method to create an editsection link,
that
> >> method IS part of Skin itself now.
> >> Also there is some compat for hooks that were passed the linker as
an
> >> instance, and `$parserOptions->getSkin();` However note that
> >> ParserOptions::getSkin no longer returns an actual Skin, it now
> returns
> >> a plain linker instance and makes a depreciated call.
> >> ((for reference the 'instance' of Linker which is static is
actually
> a
> >> "DummyLinker" class which has a __call that forwards old method
calls
> to
> >> static calls to the linker))
> >>
> >> So nearly EVERY case you are currently grabbing a Skin for, you
> should
> >> no longer be fetching a skin.
> >>
> >>
> >> Now, if you really do need a skin, the the new way to get a skin is
> >> `$context->getSkin()`, OutputPage has a helper `$out->getSkin()` if
> you
> >> happen to be working on OutputPage related stuff and need to
interact
> >> with the skin. `$wgUser->getSkin();` has some BackCompat to keep
> >> working, however please avoid using it, it uses the main
> RequestContext,
> >> not whatever the RequestContext for whatever context you are in is.
> >>
> >> Also, there is no equivalent to `$wgUser->getSkin( $title );`. Skin
> no
> >> longer has a mTitle of it's own, it gets the title used in the
> attached
> >> RequestContext, which is the same one that OutputPage uses, and is
> >> essentially the replacement to $wgTitle. So you don't need to work
> >> around bugs like that in Skin, nor in OutputPage anymore.
> Additionally
> >> that format was never actually used right, nearly every call to
that
> was
> >> actually made in contexts where one was using the Linker methods
> (which
> >> don't use mTitle) and was not interacting with the skin.
> >>
> >> I started a page on the RequestContext object:
> >> http://www.mediawiki.org/wiki/Request_Context
> >>
> >>
> > Context is very interesting. That sounds like easier way of having
> farms
> > sharing one installation path without the symlink hacks, also
probably
> > an efficient "in-farm transclusion".
> > Dmitriy
> Symlink hacks?
> You can already make a farm just by using a LocalSettings.php with
> conditionals based on a domain or wikiid passed to maintenance
scripts.
> Request Context only contains limted data and doesn't deal with the
> varying loading of different things like extensions. It's also
> completely orthogonal to whatv db is being loaded from so it's not
> useful at all for transclusion.
> But it should eventually provide you with a better way to faux execute
a
> page on the local wiki, and then include pieces of that into the
actual
> current page. Like what SpecialPage, LST, etc... do.
>
An instance RequestContext can be a member of MediaWiki object, for
example. In 1.15.4 I have there
function preliminaryChecks( &$title, &$output, $request )
but a
function checkInitialQueries( $title, $action ) {
global $wgOut, $wgRequest, $wgContLang;
....
}
Some methods has an output as parameter, while another uses a global.
I've checked 1.17 branch and not much changed yet. Also, it's
interesting why an ancestor of DatabaseBase is not a member of MediaWiki
object, too.
Dmitriy
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
