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.

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.


 * When writing skin code
 * You have access to the context through
 * Skin also implements a number of helpers:
 * The skin context is entered by  which is called by   external access to context sensitive method calls should be avoided.
 * The skin context is entered by  which is called by   external access to context sensitive method calls should be avoided.
 * The skin context is entered by  which is called by   external access to context sensitive method calls should be avoided.


 * 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. Until those are eliminated we cannot expect custom contexts to work perfectly and will need to keep the same workarounds, however if we fix code to stop using those globals then something like this should be possible:

Utiliser un 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.

When designing a class api it is preferable to just use a context source and not require a separate title (or by extension WikiPage) as an argument. As the calling api would be better off making use of a DerivativeContext if it needs to pass a different context to your class api.

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. If you are writing an API which uses type hinting in the arguments or makes instanceof checks you should check for IContextSoure, NOT for 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. However unfortunately because we cannot use traits yet if you need to make your class extend from another class you will have to  and implement the helper boilerplate directly in the class.

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. As we unfortunately can't use traits to allow something like this:

Utiliser l'édition de liens seule
If your extension needs 1.18 compat and you want to use linker methods this trick can get you a linker instance you can use:

Now instead of using a skin instance to access the linker just use $linker->, and you'll be able to update to Linker:: when you drop pre-1.18 compatibility.