On 04/01/11 12:12, Ilmari Karonen wrote:
On 01/03/2011 11:09 PM, Aryeh Gregor wrote:
On Mon, Jan 3, 2011 at 12:23 AM,
MZMcBride<z(a)mzmcbride.com> wrote:
It looks like a nice usability fix. :-) (Now to
get Special:MovePage turned
into ?action=move....)
I'd do the opposite -- stop using actions other than view, and move
everything to special pages. (Of course we'd still support the
old-style URLs forever for compat, just not generate them anywhere.)
The set of things that are done by actions is small, fixed, and
incoherent: edit, history, delete, protect, watch; but not move,
undelete, export, logs, related changes. The distinction is
historical -- I assume most or all of the action-based ones came about
before we had such a thing as special pages. It would be cleaner if
we only had special pages for doing non-view actions.
I think we've had both actions and special pages from the beginning
(well, since r403 at least). I suspect it's just that adding new
special pages was easier than adding new actions, so people tended to
pick the path of least resistance.
Special pages are nice because they have a base class with lots of
features. They are flexible and easy to add.
The main problem with actions is that most of them are implemented in
that horror that is Article.php.
We could have a class hierarchy for actions similar to the one we have
for special pages, with a useful base class and some generic
internationalisation features. Each action would get its own file, in
includes/actions. This would involve breaking up and refactoring
Article.php, which I think everyone agrees is necessary anyway.
The reason actions exist, distinct from special pages, is that it was
imagined that it would be useful to have a class hierarchy for
Article, along the lines of its child class ImagePage. Actions were
originally implemented with code like:
if ( $namespace == NS_IMAGE ) {
$wgArticle = new ImagePage( $wgTitle );
} else {
$wgArticle = new Article( $wgTitle );
}
$wgArticle->$action();
CategoryPage and the ArticleFromTitle hook were later added, extending
this abstraction. An object-oriented breakup of action UIs would need
code along the lines of:
$wgArticle = MediaWiki::articleFromTitle( $wgTitle );
$actionObject = $wgArticle->getAction( $action );
$actionObject->execute();
That is, a factory function in the Article subclass would create a UI
object. Each action could have its own base class, say
ImagePageViewAction inheriting from ViewAction. It's possible to have
the same level of abstraction with special pages:
class SpecialEdit {
function execute( $subpage ) {
$article = MediaWiki::articleFromTitle( $subpage );
$ui = $article->getEditUI();
$ui->edit();
}
}
So it could be architecturally similar either way, plus or minus a bit
of boilerplate. But special pages wouldn't automatically be
specialised by article type, so code common to all article types may
end up in the special page class. This could be a loss to flexibility,
especially for extensions that use the ArticleFromTitle hook.
I agree that special page subpages are a nice way to implement
actions, at least from the user's point of view. The URLs are pretty
and can be internationalised. Drupal has a similar URL scheme, and it
works for them.
However, in MediaWiki, the use of special subpages makes the handling
of long titles somewhat awkward. Many database fields for titles have
a maximum length of 255 bytes, and this limit is exposed to the user.
To allow titles approaching 255 bytes to be moved etc., there is a
hack in Title.php which lifts the length limit for NS_SPECIAL only.
This means that the names of special subpages cannot, in general, be
stored in title fields in the database. This has rarely been a problem
so far, but if we move to using special subpages exclusively, we may
see a few bugs filed along these lines.
Of course, an action URL can't be stored as a title either, so it's
not much of a point in their favour.
Just some thoughts for discussion.
(I know Aryeh makes up his mind about things like this rather faster
than I do; I look forward to his reply which will no doubt tell me all
the reasons why he's not changing his position.)
-- Tim Starling