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.

Composed UI
In composed mode, it's a bit unclear which ContentHandler should provide the Action handler for  or. Options include: Action handlers are responsible for composing the UI for viewing or editing multiple slots. The action handler therefore needs to be able to enumerate all (primary) slots.
 * The main slot's content handler
 * A handler configured per namespace (doesn't have to be a full ContentHandler, just something that can provide Action objects).

Viewing
Considerations: See also Output caching.
 * Each Content for each slot will provide a separate ParserOutput object, which can be used to include style sheets and scripts, record the usage of images, store information in page_props, etc.
 * Per default, view rendering code for each slot will be called, one after the other (we will probably want a ContentView interface). Some slots may just append to the pages main content, while others may just provide information to the skin (for sitelinks, categories, etc).
 * TBD: how do we determine, save, or change the order of slots?
 * In some cases it may be desirable to combine the display of multiple slots.
 * TBD: where does visualization code that knows about multiple slots live?

See also Revision Retrieval.

EditPage

 * 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.

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

Listings
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.