* Happy-melon <happy-me...@live.com> [Fri, 4 Jun 2010 10:03:14 +0100]: > > "Dmitriy Sintsov" <ques...@rambler.ru> wrote in message > news:1006208056.1275619880.71836632.61...@mcgi66.rambler.ru... > > * Happy-melon <happy-me...@live.com> [Fri, 4 Jun 2010 00:33:30 +0100]: > >> > >> > >> One way to achieve this would be to develop the MediaWiki class to > >> actually > >> be what it originally promised: an object representing a wiki, of > > which > >> there can in principle be more than one instantiated at any one time. > >> Configuration options could determine how the MediaWiki object > > accesses > >> data, and consequently what sub-entities it is able to produce. > >> > > Current MediaWiki class has some shortcomings. For example, when I've > > tried to setup rendering urls in my very own way and not using > > mod_rewrite, I've "cloned" and "refactored" index.php. The problem was > > with the following call: > > > > # warning: although instances of OutputPage and others are passed, > > # they are sometimes used as "fixed" wg* globals in other classes > > # so you cannot pass a non-global here, or use the different names > > # of passed instances > > $MW->initialize( $wgTitle, $wgArticle, $wgOut, $wgUser, $wgRequest ); > > > > First, I've made an instance of OutputPage with variable name > different > > from default $wgOut. And $wgArticle, too. The engine didn't work as > > expected, it still was looking for the default names here and there. I > > was forced to use default wgOut and wgArticle names. But, then, there > is > > no real incapsulation and there is no point to pass these as method > > parameters.. > > > > I'd imagine that "emulated" request or api through the local farm can > be > > done really fast, while real remote interwiki call would be done in > > usual way (api). > > Dmitriy > > Indeed; it does need a lot of work; doing it properly would probably > deprecate all the state globals ($wg(Title|Parser|Article|Out|Request) > etc); > replacing them with member variables of the MediaWiki class. How other > classes would access those variables is an interesting question; I could > see > an Article::getWiki()->getOut() chain, but that won't work for static > functions. It would be a major overhaul, but would probably kill > several > birds with one stone. > Hundreds of extensions would break :-( Compatibility is a huge burden. A crude but simpler approach would be having these globals saved in some context data structure and introduce Farm->switch() method, which would save/replace all the globals. Much less of core has to be changed, then. However, that's a bit more unreliable and risky. However, the code is fragile, anyway (from my exp, one typo sometimes can cause dreaded errors). Dmitriy
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
