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, MZMcBridez@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