Multi-Content Revisions/Views

Some UI actions (in particular,,  ) can be performed either for all slots at once ("composed" UI), or for a specific slot. The composed mode is the default, single-slot mode is triggered by setting a request parameter.

Single-Slot UI
In single-slot mode, the ContentHandler for the given slot's content is used to determine the Action handler to use for constructing the UI and handling the request.

Note that in some cases, the display of one slot may still require access to data from another slot. One example would be the display of a blame map on top of the original content.

Action Handling
Currently, there is a system of action overrides used to provide specialized viewing and editing interfaces for different content models. This mechanism needs to be overhauled to cater to multi-content revisions. In hindsight, attaching the action handling to the content model seems somewhat misguided. The system of action overrides should be largely removed, and replaced by a system that caters more directly to the semantics of the view, edit, and submit actions:
 * remove getActionOverrides from Article, WikiPage, and ContentHandler.
 * perhaps introduce a hook for overriding actions on the fly, or allow actions to be overwritten per namespace.
 * TBD: factor the undo, rollback, and restore out of the edit action.

View Action
Handling a view action:
 * 1) Determine the action handler using Action::factory (or an ActionFactory service)
 * 2) The default ViewAction will determin the PageView to use. PageViews are configured per namespace. The PlainPageView replaces the old Article class. There are two additional PageView implementations: FilePageView for the file namespace, and CategoryPageView for the category namespace.
 * 3) The PageViews have access to the Revision object to display. PageView implementation call ContentHandler::getContentView on the main slot's content handler, to get the main ContentView.
 * 4) ContentView implementations get access to all slots, and the name of "their" slot. The DefaultContentView calls getParserOutput on each slot's Content object, and merges each into the OutputPage object. (TBD: or call the other slot's ContentViews?)

TBD: PageView interface

TBD: ContentHandler::getContentView(...).

TBD: ContentView interface

TBD: In some cases it may be desirable to combine the display of multiple slots.

TBD: how do we determine, save, or change the order of slots

TBD: can we have "silent" slots that are invisible per default?

TBD: can we put slots into different "areas" on the page, instead of concatenating them all in the main content area?

TBD: old revisions and multi-slot diffs

See also Output caching.

See also Revision Retrieval.

Edit Action
Handling an edit action
 * 1) Determine the action handler using Action::factory (or an ActionFactory service)
 * 2) The EditAction creates an EditInteractor
 * 3) Editing is controlled by an EditInteractor that interprets the request parameters, validates input, triggers saving, and performs error handling and recovery (such as edit conflict resolution). Much of the functionality of EditPage can be factored into EditInteractor. EditInteractor also provides UI controls for saving, previewing, etc. It does not however provide the edit controls (such as a text area), though.
 * 4) For each slot that is directly editable (see ContentHandler::supportsDirectEditing), the respective ContentHandler provides an EditForm.
 * 5) Each EditForm is rendered one after the other, each initialized with the respective slot's current content.

TBD: describe submit

TBD: describe conflict resolution

TBD: describe preview and diff view

TBD: describe undo, rollback, and restore

TBD: EditInteractor

TBD: EditForm interface and operation

Notes:
 * Per default, one edit form is shown for each primary slot.


 * This requires some sort of EditForm interface to be factored out of EditPage.


 * The different EditForm implementations will have to use prefixes for field names to avoid collisions.
 * Some editors may integrate the editing of multiple slots (e.g. visual editor may provide UI for editing categories and infoboxes in addition to the text body).
 * TBD: how does an EditForm tell the caller which slots it will take care of?
 * TBD: how to integrate API based editing (e.g. in Wikibase) with Form-Based editing? The two interaction models are not really compatible.
 * See also: MediaWiki should provide a pluggable registry for editor interfaces.

See also Page Update Controller.

See alsoo T120414: RFC: MediaWiki should provide a pluggable registry for editor interfaces

Diffs
In diff views, diffs for each primary slot are calculated and shown, one below the other.

Submit Action
The submit action is (per default) handled by the same EditInteractor as the edit action.

History Action
TBD

Listings on Special Pages
Pages that list revisions, like RecentChanges, Watchlist, the page history, UserContributions, and so forth, do not necessarily need to expose information about slots. However, it could be useful to display which slots where changed, and also to allow filtering by slot.

Derived Content
Derived content can be viewed directly using the  request parameter (by definition, derived content cannot be edited). Derived content is not considered in diffs (though diffs could, in theory, be stored as derived content).

Some views may use derived content to enrich their output, but this requires the view code to know about the specific role and content model of the slot they want to use.