Manual:ContentHandler/fr

La fonctionnalité ContentHandler est un mécanisme qui permet la prise en charge de types de contenu arbitraires sur les pages 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 le tex ou le markdown.
 * se débarasser des cas particuliers pour les pages CSS et les pages JavaScript
 * enregistrer et mettre à jour les données de configuration structurées d'une manière plus facile que par exemple celle utilisée par les extensions de Gadget sur MediaWiki:Gadgets-definition, ou le LanguageConverter sur les pages MediaWiki:Conversiontable***.
 * fournir des pièces jointes aux pages de wikicode, par exemple pour les coordonnées géographiques (en utilisant un modèle de contenu multiparties pour les pages, similaire aux pièces jointes des courriels, en utilisant le format multiparties des messages). Ceci n'a jamais été concrétisé et maintenant est remplacé par.
 * faire la transition vers un système où les catégories, etc. ne sont pas maintenues dans le wikicode lui-même, bien qu'elles restent stockées et versionnées de manière habituelle (là aussi, en utilisant un modèle de contenu multiparties).
 * enregistrer pour Wikidata les données structurées facilement et de manière native comme contenu de page.



Idée de conception
L'idée est de stocker les autres types de données exactement de la même manière que le wikicode aujourd'hui, mais en indiquant à MediaWiki le type du contenu qu'il rencontre sur chacune des pages. Ainsi, tout type de données peut être utilisé comme le contenu d'une page wiki et enregistré et versionné exactement comme avant. Pour réaliser ceci, le noyau MediaWiki a implémenté les éléments suivants :


 * suivre le modèle de contenu de chaque page. Ceci est fait principalement dans la table de la base de données (aussi dans les tables  et ), et rendu accessible au travers des classes du noyau telles que ,   et  . Le modèle de contenu définit le format natif du contenu, sous forme de chaînes de caractères, dans une structure de tableaux imbriqués, ou un objet PHP. Toutes les opérations sur le contenu sont réalisées sur cette 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.
 * Dans le cas d'un contenu à plat (tel que le wikicode), la forme native du contenu est la même chose que la forme sérialisée (en clair, c'est une chaîne). Néanmoins on peut concevoir que, à l'avenir, la forme native du wikicode soit une forme de AST ou de DOM.
 * La table enregistre le modèle de contenu pour la version actuelle, alors que  enregistre le modèle de contenu et le format de sérialisation. Le modèle et le format peuvent changer en théorie selon la version, mais cela ne serait pas compréhensible, ni significatif avec les 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)

