Manual:Architectural modules/Action

From mediawiki.org
Module
MediaWiki
Responsibilities Different types of actions, that can be performed on pages in MediaWiki
Implementation Grouped in the package action with Action as the base class

Responsibilities[edit]

Module Action reflects different types of actions, that can be performed on pages in MediaWiki. The basic action is a view action to see the page, other actions can be watch, delete, edit etc. The module Action implements handling of these actions and performs the required processing of corresponding requests.

Overview of classes in Action module
Actions and their handlers

The following actions are present in MediaWiki:

  • View – to view a page
  • Edit – to edit a page in edit form
  • Submit – to submit the changes made to page
  • Delete – to delete a page
  • Rollback – to rollback the last edit made to the page
  • Watch/Unwatch – to add/remove a page to/from the watchlist
  • Protect/Unprotect – to change the protection levels of the page
  • Markpatrolled – to mark an edit as patrolled, i.e to indicate that it is good and beneficial
  • Render – to output the HTML content of the article, but only the text (without user interface to search, view history etc.)
  • Purge – to clear the page's cache
  • History – to view the history of the page edits
  • Raw – to show the raw content of the page in wiki text
  • Credits – to show a list of people who contributed to the page
  • Info – to show information about the page (page protection, edit history, page properties etc.)
  • Revisiondelete – to change visibility for selected revisions
  • Revert – to revert to a previous version of a file

Implementation Information[edit]

Actions are grouped in the package action. The base class is called Action and all other types of actions inherit from it. The inheritance diagram can be seen on the figure Overview of classes in Action module. There are 2 groups of actions: FormAction and FormlessAction. The first one shows a form and after that does something with the input, the second one just does something without showing a form. As it can be seen on the diagram, every action has its own class and some actions inherit from a super class action.

In some cases the actions (the controllers for them) are implemented inside the corresponding action classes, in other cases these classes are simple stubs, that call methods in the classes Article or EditPage. The figure Actions and their handlers shows the action classes, the controllers with business logic to process those actions and database access classes, where the actual read/write operations take place. As it can be seen, there is no consistency in implementing actions. For example, the handling of 'protect' action is spread over 3 classes: ProtectAction, Article and WikiPage, while the handling of 'info' action is completely done within InfoAction class. It should be mentioned, that the page information needed for 'render' and 'view' actions is received in the very early step of request processing and thus does not sequentially follow the Article:view(). That is why there is no arrow between these two steps. Furthermore, there are several methods that are used in WikiPage class to acquire relevant data and for that reason there is no specific method mentioned.