Manual:ContentHandler/zh

内容处理器（ContentHandler）是一种在维基页面上支持任意内容类型的机制，而不是一切都依赖于维基文本来处理所有内容. 这原先是作为维基数据项目的一部分开发的，从1.21版本开始成了MediaWiki核心的一部分.

有关内容处理器架构的典型概述，请参阅 MediaWiki 代码文档中的内容处理器.

有关可用的内容处理器的列表，请参阅.

关于
这一相当激进的改变背后的原因是，在MediaWiki中，被迫依赖wikitext来获取所有内容使得很多事情变得相当麻烦. 新的可插拔架构适用于任意类型的页面内容，这将使我们能够：


 * 在部分或全部页面上使用不同的标记语言，如TeX或Markdown.
 * 取消CSS和JavaScrip 页面的特例.
 * 存储和编辑结构化配置数据的方式比Gadgets扩展在MediaWiki:Gadgets-definition页面或 LanguageConverter在MediaWiki:Conversiontable***页面上使用的方式更合理.
 * 为 wikitext 页面提供数据“附件”，例如地理数据（使用页面的“多部分”内容模型，类似于使用多部分信息格式实现电子邮件附件的方式）. （注：该计划从未实现，现已被取代）.
 * 过渡到不在维基文本中维护类别等内容的系统，但仍以通常的方式进行存储和版本控制（再次使用多部分内容模型）.
 * 为維基數據轻松存储结构化数据，并将其作为页面内容.



设计理念
我们的想法是，以与目前存储 wikitext 完全相同的方式存储其他类型的数据，但要让MediaWiki知道每个页面所处理的内容类型. 这样，任何类型的数据都可以用作维基页面的内容，而且其存储和版本控制都与以前完全一样. 为了实现这一目标，我们在MediaWiki核心中实现了以下功能：


 * 追踪每个页面的“内容模型”. 这主要是在数据库中的表（也包括和表）中完成的，并可通过 、 、和 等相关核心类访问.  The content model defines the native form of the content, be it a string containing text, a nested structure of arrays, or a PHP object. All operations on the content are performed on its native form.
 * keep track of the content format (serialization format) of every revision. This is done primarily in the table in the database (also in the  table, but not in the  table), and made accessible through the relevant core classes such as  . Note that the serialization format is only relevant when loading and storing the revision, no operations are performed on the serialized form of the content.
 * Note: in case of flat text content (such as wikitext), the native form of the content is the same as the serialized form (namely, a string). However, conceivably, the native form of wikitext could be some form of AST or DOM in the future.
 * Note: the table records the content model for the current revision, while the  records the content model and serialization format. Model and format may in theory both change from revision to revision, though this may be confusing, and doesn't allow for meaningful diffs.

This means that all code that needs to perform any operation on the content must be aware of the content's native form. This knowledge is encapsulated using a pluggable framework of handlers, based on two classes:


 * The  class represents the content as such, and provides an interface for all standard operations to be performed on the content's native form. It does not have any knowledge of the page or revision the content belongs to. Content objects are generally, but not necessarily, immutable.
 * The  class, representing the knowledge about the specifics of a content model without access to concrete Content. Most importantly, instances of ContentHandler act as a factory for Content objects and provide serialization/deserialization. ContentHandler objects are stateless singletons, one for each content model.

The ContentHandler is also used to generate suitable instances of subclasses of,  ,  , etc. This way, a specialized UI for each content type can easily be plugged in through the ContentHandler interface.

All code that accesses the revision text in any way should be changed to use the methods provided by the Content object instead. Core classes that provide access the revision text (most importantly,  and  ) have been adapted to provide access to the appropriate Content object instead of the text.



向后兼容
The assumption that pages contain wikitext is widespread through the MediaWiki code base. To remain compatible with parts of the code that still assume this, especially with extensions, is thus quite important. The right way to provide good compatibility is of course not to change public interfaces. Thus, all methods providing access to the revision content (like, etc.) remain in place, and are complemented with an alternative method that allows access to the content object instead (e.g. ). The text-based methods are now deprecated, but shall function exactly as before for all pages/revisions that contain wikitext. This is also true for the action API.

A convenience method,, is provided to make it easy to retrieve a page's text. For flat text-based content models such as wikitext (but also JS and CSS),  will just return the text, so the old text-based method will return the same as it did before for such revisions. However, in case a text-based backwards-compatible method is called on a page/revision that does not contain wikitext (or another flat text content model, such a CSS), the behavior depends on the setting of : ignore makes it return null, fail causes it to raise an exception, and serialize causes it to return the default serialization of the content. The default is ignore, which is probably the most conservative option in most scenarios.

For editing however, non-text content is not supported per default. and the respective handlers in the action API will fail for non-textual content.

链接

 * 和 类 :


 * -{zh-hans:设置; zh-hant:設定;}- :


 * 使用内容处理器的扩展 :
 * 如何添加带有扩展名的内容模型：
 * 基本例子： Extension:Markdown
 * 扩展
 * — 所有内容模型的列表（包括核心和扩展中的）
 * — 所有内容模型的列表（包括核心和扩展中的）