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 les.
 * 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. Ceci est fait principalement dans la table de la base de données (aussi dans la table  mais pas dans ), et rendu accessible au travers des classes du noyau telles que  . Notez que le format de sérialisation est seulement significatif quand la révision est chargée ou enregistrée, aucune opération n'est réalisée sur la forme sérialisée du contenu.
 * 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.

Cela signifie que tout code devant réaliser une opération sur le contenu doit connaître la forme native de ce contenu. Cette connaissance est encapsulée en utilisant un environnement greffable de gestionnaires et reposant sur deux classes :


 * La classe  représente le contenu comme tel, et fournit une interface pour toutes les opérations standard à réaliser sur la forme native du contenu. 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.
 * La classe, représente la connaissance sur les spécificités d'un modèle de contenu sans accéder concrètement à la partie 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)

