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
---- some extra ---- I'm still contemplating skin setting and relation to context right now. I would like to make it possible to do something like `$context->setSkin( new DummyOfflineSkin );` but also want to avoid bugs where you try to set the same skin onto two contexts and get an error. I examined the code paths, and Skin doesn't actually make any RequestContext dependent calls except inside calls made from the Skin::outputPage( $out ); entrypoint which is called by OutputPage::output();, in other words theoretically I could avoid tying a Skin instance to any specific context by setting the context at the start of Skin::outputPage( $out ) ($out provides the RequestContext), and exiting that context when it's done. However there is one instance where this rule is broken, ApiParse which makes a direct call outside of that context when you use categoryhtml or languagehtml (which I wanted to stop from being released from the start).
On Mon, Apr 4, 2011 at 6:06 PM, Daniel Friesen lists@nadir-seen-fire.comwrote:
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.
I was about to go "nooooo!" because mixed static/nonstatic functions throw deprecation warnings these days, but I see you've done this by separating the classes entirely and using a magic __call handler on Skin to forward the calls, neatly sidestepping the issue and avoiding writing a bunch of stubs. Yay!
That should work, but feels a little icky. :D But if it's just for back-compat and we're migrating code over, then that's probably not a problem... Main thing to keep in mind is that exceptions thrown from a __call function for unknown stuff will act differently from the fatal error you otherwise get from misspelling a function name, as exceptions are catchable etc. This can sometimes lead to surprises.
We also lose the documentation comments on the functions as they're currently used on Skin, but if that's being deprecated, not too big a deal.
A bigger worry: DumpHTML's SkinOffline overrides makeBrokenLinkObj to change behavior (looks like it never got updated to override link()'s behavior for broken-link case?). Looks like that might need to be updated to use BeginLink/EndLink hooks or something... but I'm not sure how good a shape DumpHTML's in right now, it might need many more such fixes.
-- brion
On 11-04-05 02:16 PM, Brion Vibber wrote:
On Mon, Apr 4, 2011 at 6:06 PM, Daniel Friesenlists@nadir-seen-fire.comwrote:
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.
I was about to go "nooooo!" because mixed static/nonstatic functions throw deprecation warnings these days, but I see you've done this by separating the classes entirely and using a magic __call handler on Skin to forward the calls, neatly sidestepping the issue and avoiding writing a bunch of stubs. Yay!
That should work, but feels a little icky. :D But if it's just for back-compat and we're migrating code over, then that's probably not a problem... Main thing to keep in mind is that exceptions thrown from a __call function for unknown stuff will act differently from the fatal error you otherwise get from misspelling a function name, as exceptions are catchable etc. This can sometimes lead to surprises.
We also lose the documentation comments on the functions as they're currently used on Skin, but if that's being deprecated, not too big a deal.
A bigger worry: DumpHTML's SkinOffline overrides makeBrokenLinkObj to change behavior (looks like it never got updated to override link()'s behavior for broken-link case?). Looks like that might need to be updated to use BeginLink/EndLink hooks or something... but I'm not sure how good a shape DumpHTML's in right now, it might need many more such fixes.
-- brion
- Overrides a linker method - Uses deprecated poweredbyico and copyrightico - Is completely out of date as a skin, no use of headelement, footerlinks, blah, blah, blah... - Overrides the method generating content_actions instead of using content_navigation - Creates an OutputPage instead of using RequestContext
I don't really like the fact that DumpHTML handles skin stuff by copying Monobook and making some overriding hacks in it. I'm starting to thing we should drop SkinOffline, create an offline/dump/static render mode inside skin or outputpage to be used to make some of the minor tweaks to skin markup relevant to static outputs, and make DumpHTML work by setting that offline mode, making calls to OutputPage to alter what scripts/styles are loaded, and using hooks to alter the behaviour of links made from the linker. And as a bonus: - We won't have to modify a clone of MonoBook anymore - And we'll be able to make dumps from any skin you want, including Vector, Modern, or any custom skin you build.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On 05.04.2011 5:06, Daniel Friesen wrote:
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
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.
* Daniel Friesen lists@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
On Mon, Apr 18, 2011 at 1:03 AM, Dmitriy Sintsov questpc@rambler.ru wrote:
Also, it's interesting why an ancestor of DatabaseBase is not a member of MediaWiki object, too.
What if you needed to switch between DB_MASTER and DB_SLAVE? Easier to just call wfGetDB() as needed.
-Chad
* Chad innocentkiller@gmail.com [Mon, 18 Apr 2011 01:07:09 -0400]:
On Mon, Apr 18, 2011 at 1:03 AM, Dmitriy Sintsov questpc@rambler.ru wrote:
Also, it's interesting why an ancestor of DatabaseBase is not a member of
MediaWiki
object, too.
What if you needed to switch between DB_MASTER and DB_SLAVE? Easier to just call wfGetDB() as needed.
Ok, I didn't think about that. I do not run MySQL cluster. However, multiple instances can be stored as member of MediaWiki object. But, anyway - maybe that's not needed. I just saw the trend "against the globals" and thought that it can be "generalized". Dmitriy
On Mon, Apr 18, 2011 at 7:20 AM, Dmitriy Sintsov questpc@rambler.ru wrote:
- Chad innocentkiller@gmail.com [Mon, 18 Apr 2011 01:07:09 -0400]:
On Mon, Apr 18, 2011 at 1:03 AM, Dmitriy Sintsov questpc@rambler.ru wrote:
Also, it's interesting why an ancestor of DatabaseBase is not a member of
MediaWiki
object, too.
What if you needed to switch between DB_MASTER and DB_SLAVE? Easier to just call wfGetDB() as needed.
Ok, I didn't think about that. I do not run MySQL cluster. However, multiple instances can be stored as member of MediaWiki object. But, anyway - maybe that's not needed. I just saw the trend "against the globals" and thought that it can be "generalized".
I agree with this. wfGetDB() is just an elaborate way to to access the LoadBalancer singleton, which in itself is just a global in disguise.
Bryan
wikitech-l@lists.wikimedia.org