Hi Daniel, thanks for letting us know. Could you please add the relevant details to http://www.mediawiki.org/wiki/Manual:Extension_support/1.19/ExtUpgradingand http://www.mediawiki.org/wiki/Manual:Extension_support/1.18/ExtDowngrading so that extension programmers know what to do?
Thanks, Olivier Beaton On Tue, Nov 22, 2011 at 9:04 AM, Daniel Friesen <[email protected]>wrote: > I've added a few lightly abstract methods to replace some of the direct > comparisons we make related to namespaces. > > When you want to see if a title is part of a namespace, instead of writing > this: > $title->getNamespace() == NS_USER > > You can now (or rather, if you don't have compat issues, PLEASE DO use it): > $title->inNamespace( NS_USER ); > > When you need to make a test if a page is part of a subject or a talk eg > either User or User_talk instead of something verbose like: > $title->getNamespace() == NS_USER || $title->getNamespace() == NS_USER_TALK > > Please use: > $title->hasSubjectNamespace( NS_USER ); > > hasSubjectNamespace will return true if the title's namespace's subject > namespace matches the subject namespace of the namespace you pass in. > > If you're writing verbose code testing if a title is in any of a number of > namespaces by using in_array you can use inNamespaces (note the 's'): > $title->inNamespace( NS_USER, NS_TEMPLATE ); > > To be honest, I don't have any good example use cases on hand of where you > would use that, but I didn't want the lack of that functionality and the > simplicity of in_array to be a valid rationale in not making use of these > abstract interfaces to namespace info. > > Likewise there are two MWNamespace methods to match. MWNamespace::equals > and MWNamespace::subjectEquals. > > And I DO encourage people making $ns == NS_???? comparisons to use > MWNamespace::equals( $ns, NS_???? ) instead. Even though technically right > now MWNamespace::equals is in fact `return $ns1 == $ns2;`. > > > > This is a little relevant to the "MediaWiki should use a reservation > system for namespaces" bug: > https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 > > The idea is essentially to drop our practice of passing around integers > and instead start passing around keys like "USER", "SMW_PROPERTY", etc... > MediaWiki would have a namespace registration system where when given a > new key it would reserve a new namespace number for that key. > Instead of extensions being forced to declare what integers they are going > to use and coordinate with other extension developers so that extensions > don't conflict they can instead just make a call to MediaWiki declaring a > string based key like "SMW_PROPERTY" which should not be confusable with > another extension and then MediaWiki will register an integer in the > database for that namespace and reserve it for use with that key. This > also has the benefit that if you install an extension then uninstall it, > you shouldn't lose the contents of the namespace, and when you re-install > it'll start working again without issues like conflicts with titles > created in NS_MAIN that match the prefix used. Theoretically changing the > content language of your wiki from say 'fr' to 'it' could be made in such > a way that MediaWiki won't break existing links and instead the old > i18n'ed NS will end up as an alias. > The idea also fits in with another bug asking for a namespace manager ui. > If we switch to a namespace registration system it will be much easier to > create an administrative ui for this. > > Having these abstract interfaces for namespace comparison around will mean > that in the future if we do in fact start passing around things like > "USER" instead of integers, there should be no issue of bugs cropping up > if some code happens to come together and for an unfortunate reason you > happen to have both "USER" and `2` passed from different sources. Making > use of Title::inNamespace and MWNamespace::equals will ensure that even if > you have "USER" and `2` they will be considered equivalent. Unlike what > would happen if you'd used == directly. > > -- > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
