dan_the_man at telus
May 9, 2008, 5:20 AM
Post #2 of 5
(262 views)
Permalink
|
|
Re: Special:SpecialPages and commit r33197
[In reply to]
|
|
Agreed, SpecialPage:setGroup( $pagename, $group ); is not good to use.
We used to use SpecialPage:addPage( Object ); to add in new special
pages. Except this ends up loading both the SpecialPage class, and the
class for the extension. Honestly I'm guilty of still using it because I
only recently found out that even before I started using it the thing
had been depreciated and the proper way to add a new special page was to
add the array with it's class name and constructor to $wgSpecialPages.
However, the current setGroup actually just appends to
$wgSpecialPageGroups. So we should be treating this in the same way. The
SpecialPage addPage and setGroup functions do exist. But they should be
both considered depreciated functions there only for compatibility with
old extensions and the misinformed. Everyone should be using
$wgSpecialPages and $wgSpecialPageGroups in their extensions.
Honestly, now that I think about it anything added to
$wgExtensionFunctions probably shouldn't be part of a big class integral
to an extension. For cleanest code it should probably still be ok to
have a class with the name of the extension and have it contain the
various MagicWord hook methods, ExtensionFunctions and such. But leave
SpecialPage classes and methods for anything like ParserFunctions in
other classes in other files which will only be loaded when and if needed.
Though I would like to improve on the style:
Take a look at Special:Version's look:
http://dev.wiki-tools.com/wiki/Special:Version
But look at Special:SpecialPages:
http://dev.wiki-tools.com/wiki/Special:SpecialPages
Special:Version uses some nice styles, and tables, and even borders
things. All by default.
But Special:SpecialPages uses ugly boxes. I'd say they could use some
margin and bordering on them.
Actually on the note of the looks...
Open up Special:SpecialPages, and then reduce the width of your browser.
Notice that blank space?
Inspecting the elements you see something... Special:SpecialPages is
reserving an entire td for a third column that is never used. Either
remove the td making it 2 columns, or actually use 3 columns. No reason
to stick in a huge gap which could either be used to reduce the large
height that Special:SpecialPages still takes up, or avoid any line
breaking when the screen size is reduced.
And lastly, we have those headings...
Special:SpecialPages is still outputting the awful "Special pages for
all users" and "Restricted special pages" headers. Not only are they
completely ugly when paired with the grey boxes, and take up even more
space then they do. It's quite pointless to have them with all these
other nice headings. We should either merge restricted special pages
into the categorization (We could always give them a different class and
highlight them, or add something like an asterisk (*) on the end of them
with a note "* Restricted special page you have access to" at the
bottom... And if you find that ugly, but note that the css class isn't
very good for those without css... Then do both, and put the asterisked
stuff there, but put it inside of a span with a class to hide it when
css is enabled...), or we should make "Restricted special pages" smaller
and style it similarly to the boxes. Basically shrink it down so it's
only a little heavier in size, and doesn't have the margin of the others
so it is a bit wider.
But whatever the case, "Special pages for all users" should never show
up... Especially when there are no restricted pages... Think about it,
what's the point of saying a bunch of pages are for everyone, when
you're not even able to see any restricted pages at all.
I kinda like the former. It lets me search for a page I want by it's
category, not by first trying to figure out if it's restricted or not.
~Daniel Friesen(Dantman) of:
-The Gaiapedia (http://gaia.wikia.com)
-Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
-and Wiki-Tools.com (http://wiki-tools.com)
Mark Clements wrote:
> Aaron recently committed an update to Special:SpecialPages [1] which adds
> the long-awaited functionality of splitting the list of pages up into
> shorter manageable sub-lists. Hurrah! However he didn't notice bug 10457
> [2] which deals with this issue and which (a) has a couple of suggested
> groupings for the various pages and (b) already had a patch (which I
> contributed) for solving this same problem.
>
> Before 1.13 comes out and this ends up in an official release I would like
> to open up some discussion about a couple of points:
>
> #1 - Extensions
>
> My patch was written to allow extensions to easily add themselves to a
> particular section, with any non-categorised extensions falling through into
> a 'misc' section at the bottom. This was deliberately designed to be
> backward compatible and easy to use.
>
> In Aaron's method, SpecialPage:setGroup( $pagename, $group ) is the code to
> use, which has two potential drawbacks:
> * Extensions need to explicitly check which version of MW they are running
> on before calling the code, otherwise errors will occur in earlier versions
> which don't have this function.
> * It requires an extra function call - this may not be a major problem (and
> may just be a subjective matter of coding style), but it is if it causes the
> SpecialPage class to be loaded permaturely (I don't know if this is the case
> or not).
>
> It would be good to get a bit of feedback on the two methods used to see
> which is considered better in terms of both future-proofing and
> backwards-compatibility (and of course any other considerations that may
> apply). Of course, if there's no particular benefit to either method then
> we should use the one that's already in place.
>
> #2 - Grouping
>
> There have now been three proposed groupings of the special pages. Aaron's
> (currently live on WMF sites), Mine (in the patch I attached to the bug) and
> Simetrical's (in the initial bug description). Obviously, I think mine is
> best, but I don't think any of them are quite right yet. It would be good
> to get some discussion and settle on a decent order.
>
> Also, in my view there should be no sections with just a single item (my
> code avoids this by moving single-item sections into 'miscellaneous', which
> would be an easy thing to add to Aaron's code) and also the default sections
> should not be as big as (for example) 'Other special pages' currently is.
>
>
> Thanks to Aaron for getting this long-awaited feature into core.
>
> - Mark Clements (HappyDog)
>
> [1] http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=33197
> [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=10457
>
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
|
