Multi-Content Revisions/Views

This page is part of the MCR proposal. Status: collecting notes.

Some UI actions (in particular, view, edit) 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 slot=foo.

Composed Views

Page Types

MediaWiki currently supports three types of pages that use different rules for output composition: regular articles, category pages, and file pages. With MCR, it should become possible to define additional types of pages. The following behavior would be decided based on the page type:

• composition of the ParserOutput object to be placed in the parser cache from the ParserOutput of the individual slots.
• required permission to change a page
• possibility to make a page (we may want to make it impossible to move a page in a way that changes its page type).
• general action overrides
• particularly the edit interface, as well as handlers for the submit action
• composition of the diff view
• edit conflict detection and automatic resolution
• UI for manual edit conflict resolution
• UI for revert and undo
• define which slots are supported (or even required). Note that "extra" slots should always be allowed to exist, even if the page type handler doesn't know what to do with them. They would just be "looped through" edits, and would remain accessible via "single slot" mode.

The page type would typically be determined based on the namespace. However, there may be a need to record the page type per page, and even per revision. If this need arises, a new table (page_type or revision_page_type) should be added that associates a page type with a given page or revision. This would allow the page type to be changed over the life time of a page.

ParserOutput and ParserCache

The parser cache should contain ParserOutput objects that represent the entire revision; the composition of the ParserOutput object from the individual ParserOutputs of the individual slots is governed by the page type handler.

We may want to also cache the per-slot ParserOutput objects in the future. This could be done by caching them under separate keys, or by making them part of the composed ParserOutput object. This implies however that all output is cached twice.

An alternative would be to only cache individual ParserOutput objects (one key per slot) or ParserOutput bundles (one key per revision), and construct the combined ParserOutput on the fly (based on the page type). Note that this is not only necessary for display, but also to perform secondary data updates after edit (as long as the code performing such updates requires a single ParserOutput object).

As a first step, a ParserOutput bundle could be a ParserOutput object that knows the per-slot ParserOutput objects it is composed of. All the getters would combine information from the per-slot ParserOutput objects on the fly - for the HTML this means plain concatenation. The "basic" page type handler would rely on this baseline behavior; specialized page type handlers can modify this behavior. This would provide backwards compatibility with code that expects a single ParserOutput object. On the other hand - if there is not too much such code, it could also just be modified to take some other representation of a ParserOutput bundle and know about the page type handler.

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.

One use of the single slot interface is to act as a fallback for cases when not all slots are shown in the regular page view, because some slots are present which the handler for the page type does not know about (due to code changes, configuration changes, imported data, etc).

Note that Single-Slot UI cannot make use of the parser cache if we only cache the composed ParserOutput object.

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.