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 multipart pour les pages, similaire aux pièces jointes des courriels, en utilisant le format multipart 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
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)

