Manual:ContentHandler/fr

La fonctionnalité ContentHandler est un mécanisme qui permet la prise en charge de types de contenu arbitraires sur les pages du wiki, plutôt que de faire référence au wikicode à chaque fois. Elle a été développée comme partie du projet Wikidata et se trouve dans le noyau MediaWiki depuis la version 1.21.

Pour la présentation canonique, voir l'architecture du ContentHandler dans la documentation du code de MediaWiki.

donne la liste des gestionnaires de contenu disponibles.

À propos
Le raisonnement derrière ce changement radical est que, si l'on se réfère au wikicode pour chaque contenu, on en arrive a faire des choses assez lourdes dans MediaWiki. La nouvelle architecture greffable pour les types arbitraires de contenu de page va nous permettre nous l'espérons de :


 * utiliser un language de balisage différent sur certaines ou sur toutes les pages, comme du tex ou du markdown.
 * se débarasser des cas particuliers pour les pages CSS et les pages JavaScript
 * store and edit structured configuration data in a more sensible way than e.g. what the Gadgets extension uses on MediaWiki:Gadgets-definition or the LanguageConverter on MediaWiki:Conversiontable*** pages.
 * provide data "attachments" to wikitext pages, e.g. for geodata (using a "multipart" content model for the page, similar to the way email attachments are implemented using the multipart message format). (Note: ceci n'a jamais été matérialisé et maintenant est remplacé par ).
 * transition to a system where categories etc are not maintained in the wikitext itself, while still being stored and versioned in the usual way (again, using a multipart content model).
 * enregistre pour Wikidata les données structurées facilement et de manière native comme contenu de page.



Idée de conception
The idea is to store other kinds of data in exactly the same way as wikitext is stored currently, but make MediaWiki aware of the type of content it is dealing with for every page. This way, any kind of data can be used as the content of a wiki page, and it would be stored and versioned exactly as before. Pour réaliser ceci, le noyau MediaWiki a implémenté les éléments suivants :


 * suivre le modèle de contenu de chaque page. This is done primarily in the table in the database (also in the  and  tables), and made accessible through the relevant core classes such as ,   and  . 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. Toutes les opérations sur le contenu sont réalisées sur sa forme native.
 * suivre le format du contenu (format de sérialisation) de chaque version. 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. Elle n'a aucune connaissance de la page ni de la version à laquelle le contenu appartient. Les objets de contenu sont généralement non mutables, mais pas nécessairement.
 * 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. Les objets ContentHandler sont des singletons sans état, un singleton par modèle de contenu.

ContentHandler est également utilisé pour générer des instances compatibles des sous-classes de,  ,  , 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.



Compatibilité arrière
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. La bonne manière de fournir une bonne compatibilité est bien sûr de ne pas modifier les interfaces publiques. 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. ). Les méthodes basées sur le texte sont maintenant obsolètes, mais elles fonctionnent exactement comme avant pour toutes les pages et les versions qui contiennent du wikicode. Ceci est vrai aussi pour l'API action.

Une méthode pratique, est fournie pour faciliter la récupération du texte des pages. 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. La valeur par défaut est ignore, qui est probablement l'option la plus conservative dans la plupart des scenarios.

Néanmoins pour les modifications, le contenu non textuel n'est pas pris en charge par défaut. et les gestionnaires respectifs de l'API Action vont échouer si le contenu n'est pas textuel.

Liens

 * classes  et   :


 * Paramètres :


 * Extensions qui utilisent ContentHandler :
 * Comment ajouter un nouveau modèle de contenu avec une extension :
 * Exemple de base : Extension:Markdown
 * Extension
 * — liste de tous les modèles de contenu (y compris dans le noyau et dans les extensions)
 * — liste de tous les modèles de contenu (y compris dans le noyau et dans les extensions)

