Manual:RequestContext.php/fr

Depuis MediaWiki 1.18 le contexte d'une requête est encapsulé dans une instance  qui implémente l'interface. Les extensions doivent appeler  puis   plutôt que de s'appuyer sur les variables globales d'état.

RequestContext: les accesseurs
Un RequestContext ou IContextSource fournit les accesseurs suivants :


 * - instance de laquelle récupérer les variables demandées.
 * - instance pour la page devant être produite.
 * - instance liée à RequestContext, et vers laquelle sera envoyée la page produite.
 * - instance de la classe à utiliser pour générer la page.
 * - instance de de l'utilisateur pour lequel la page est générée.
 * - (ajouté en 1.19 pour remplacer dorénavant obsolète) instance  de la langue de l'utilisateur dans laquelle la page est générée.
 * - instance à produire (mais voir ci-dessous).
 * - vérifie si  peut être appelé, sinon lève une exception.
 * - retourne un objet dont le contexte est initialisé comme le contexte à appeler. possède les mêmes paramètres que.
 * - objet principal

La sortie (output) et la langue (language) sont en lecture seule, le reste de RequestContext peut être initialisé en utilisant les méthodes telles que ).

Travailler avec les contextes de requête
Vous pouvez accéder au contexte principal de la requête en utilisant néanmoins ceci doit être fait en dernier recours. La plupart des endroits où vous devez faire quelque chose avec les données du contexte de requête doivent fournir un accès à une source IContextData et vous devez utiliser celle-ci et non pas l'instance principale RequestContext ni les variables globales.

Lorsque vous écrivez une SpecialPage

 * Vous pouvez accéder au contexte avec
 * SpecialPage implémente aussi un nombre d'assistants :
 * Vous pouvez utiliser pour le titre de SpecialPage et  pour le titre de la page spéciale ainsi que pour toute donnée $par.
 * Les SpecialPage sont faites pour être exécutées dans les contextes alternatifs afin que les extensions puissent démarrer sans avoir besoin d'utiliser les $wg . Il est probable que nous allons arrêter le support aux alentours de la version MediaWiki 1.20, pour les pages spéciales pouvant être incluses en utilisant les variables $wg relatives au contextes des requêtes.
 * Vous pouvez utiliser pour le titre de SpecialPage et  pour le titre de la page spéciale ainsi que pour toute donnée $par.
 * Les SpecialPage sont faites pour être exécutées dans les contextes alternatifs afin que les extensions puissent démarrer sans avoir besoin d'utiliser les $wg . Il est probable que nous allons arrêter le support aux alentours de la version MediaWiki 1.20, pour les pages spéciales pouvant être incluses en utilisant les variables $wg relatives au contextes des requêtes.
 * Vous pouvez utiliser pour le titre de SpecialPage et  pour le titre de la page spéciale ainsi que pour toute donnée $par.
 * Les SpecialPage sont faites pour être exécutées dans les contextes alternatifs afin que les extensions puissent démarrer sans avoir besoin d'utiliser les $wg . Il est probable que nous allons arrêter le support aux alentours de la version MediaWiki 1.20, pour les pages spéciales pouvant être incluses en utilisant les variables $wg relatives au contextes des requêtes.

Lorsque vous écrivez du code d'habillage

 * Vous accédez au contexte par
 * Skin implémente aussi un nombre d'assistants :
 * Le contexte de l'habilage est passé par  qui est appelé par   ; l'accès extérieur aux appels des méthodes sensibles du contexte doit être évité.

Lorsque vous utilisez des accroches

 * Si votre accroche fournit un OutputPage en tant qu'argument, alors utilisez le contexte qu'il fournit.
 * Si votre accroche s'exécute dans le contexte de sortie de la page, et qu'elle fournit une instance Skin d'habillage, utilisez le contexte qu'elle fournit.
 * Si votre accroche fournit une instance de Title, utilisez la de préférence par rapport aux autres contextes.
 * Le même principe est valable pour toutes les instances de WebRequest passées comme argument aux accroches.
 * Assurez-vous d'utiliser la bonne accroche; si vous founissez un contexte qui n'est pas le bon, alors vous utilisez probablement une accroche à tord et vous pouvez créer des bogues incohérents.
 * Néanmoins certaines accroches peuvent être obsolètes et doivent être appelées avec un nouveau contexte dans leur arguments.

Lorsque vous écrivez des fonctions d'analyseur syntaxique et des accroches

 * Les fonctions de l'analyseur syntaxique ainsi que les accroches ne doivent pas accéder aux données des contextes de requête. Les autres informations contextuelles peuvent être accédées à partir de l'objet analyseur syntaxique local.
 * Par exemple :
 * Utilisez ParserOptions pour tout ce dont vous avez besoin comme par exemple la langue de l'utilisateur.
 * Utilisez la classe Linker:: en statique au lieu d'accéder à l'habillage.
 * Si vous devez ajouter quelquechose à la page fournie, en dehors de la zone de contenu, la classe ParserOutput doit avoir les méthodes pour faire ce que vous voulez.
 * Si les méthodes de ParserOutput ne sont pas assez flexibles pour ce que vous devez faire, il est possible d'enregistrer avec ParserOutput, une procédure de rappel (callback) qui sera appelée ultérieurement à un endroit où vous pourrez utiliser librement les contexte de la requête.

Créer de nouveaux contextes de requête
Il existe encore du code qui utilise les variables globales, , et. Tant que ceux-ci n'auront pas été supprimés, il ne faut pas s'attendre à ce que les contextes personnalisés fonctionnent parfaitement et nous aurons encore besoin des solutions de contournement, néanmoins si nous corrigeons le code pour ne plus utiliser ces variables globales, alors quelque chose de similaire à ce qui suit devrait être possible :

Utiliser DerivativeContext
MediaWiki 1.19 a ajouté la classe DerivativeContext. DerivativeContext est utile si vous voulez passer un contexte à quelque chose qui est basé sur le contexte avec lequel vous êtes mais un peu différent. Par exemple un contexte qui possède tous les contextes actuels, mais a un titre différent.

Lorsque vous concevez l'API d'une classe il est préférable de n'utiliser qu'une seule source de contexte et de ne pas recourir comme argument à un titre séparé (ou par extension, une WikiPage). Comme il est préférable que l'API appelante utilise DerivativeContext si elle doit passer un contexte différent à votre API de classe.

Utiliser IContextSource et ContextSource
La base de RequestContext est l'interface. Il définit l'API d'un service à partir duquel vous pouvez obtenir des éléments du contexte de requête. Si vous écrivez une API qui utilise des type hinting dans les arguments, ou qui fait des contrôles  vous devez utiliser IContextSoure, et non pas RequestContext.

Additionnellement nous fournissons une classe d'assistant ContextSource. En faisant en sorte que votre classe soit une extension de la classe ContextSource, elle contiendra directement déja, les différents assistants getOutput, getSkin, getLanguage, etc... et sera. Néanmoins, et parce que malheureusement nous ne pouvons pas utiliser les traits cependant si vous devez étendre votre classe à partir d'une autre classe, vous devrez  et implémenter le squelette de l'assistant directement dans la classe.

A partir d'une classe ContextSource vous pouvez utiliser la méthode setContext pour initialiser le contexte dans lequel se trouve votre classe. Par exemple, un constructeur qui a besoin d'un contexte peut s'écrire ainsi :

Encore une fois, si vous ne pouvez pas étendre ContextSource vous devrez implémenter le squelette de l'assistant directement dans votre classe. Comme nous ne pouvons pas malheureusement utiliser les traits pour permettre quelque chose comme :

Utiliser l'édition de liens seule
Si votre extension nécessite la compatibilité 1.18 et que vous voulez utiliser les méthodes de l'éditeur de liens, cette astuce peut vous fournir une instance viable de l'éditeur :

Maintenant, au lieu d'utiliser une instance de l'habillage pour accéder à l'éditeur de liens, utilisez simplement  et vous pourrez mettre à jour vers Linker:: lorsque vous supprimez la compatibilité pré-1.18.