Extension:JsonConfig/fr

L'extension JsonConfig permet aux autres extensions de stocker leurs données de configuration en tant que blob JSON à l'intérieur d'une page wiki.

Fonctionnalités disponibles et cas d'utilisation

 * You may use JsonConfig to store data in a number of ways:
 * in a single configuration page, e.g. a number of settings for your extension in "Config:MyExtSettings ( is the default namespace associated with the JsonConfig extension);
 * in a set of pages with similar structure residing in their own namespace, e.g. IP addresses of known proxies or event log schemas named "Proxy:Opera", or schemas named Schema:AccountCreation
 * using it only for pages whose titles match a regex pattern, e.g. Config:Proxy:Opera or Config:Opera.proxy. This avoids filling a wiki with lots of namespaces, one for each content model.
 * You may provide a content class to do data validation (beyond valid JSON) and normalization.
 * You may provide a view class to customize HTML display.
 * You can store data:
 * "one-per-wiki", "one-per-cluster", or even one per some "family" (different structure of the caching key for shared memcached);
 * in a public or private wiki and accessed with credentials;
 * in a separate cluster, and do remote notification when changed.

Current

 * Commons tabular data sets
 * Commons map data sets
 * Dashiki dashboard configurations
 * Others?

Past

 * Wikipedia Zero operator configurations (see Extension:ZeroBanner)

Cette variable définit les profils pour chaque type de page de configuration. est un tableau associatif de sous-tableaux dont chacun contient zéro ou plusieurs des paramètres suivants. Par défaut, JsonConfig utilise la clé en chaîne de caractères comme ID du modèle représenté par ce profil, mais si vous voulez réutiliser le même ID de modèle dans plusieurs profils, vous pouvez la réécraser à l'aide du praramètre.

Cette variable déclare l'ID du modèle géré par chacune des classes de contenu personnalisées. La même classe de contenu peut gèrer plusieurs ID de modèles. Toutes les classes de contenu doivent dériver de la classe  ;  si le modelID correspond à , alors la classe par défaut   prend en charge l'ID du modèle.

Exemple :

Si vous implémentez une classe séparée pour la génération du HTML, vous pouvez spécifier votre modèle de configuration comme un tableau avec une classe supplémentaire  :

Hello World
The simplest case is a single configuration page without any validation, stored locally on each wiki. Just add these settings to LocalSettings.php

The above enables namespace "Config" on the local wiki, but only allows the "Config:MySettings" page to be created, not any other page in that namespace. You can store well-formed JSON data in the page.

To read the MySettings data in PHP, use a  object to access the page, then request its content:

Congurations multiples partagées au sein d'une grappe
Lets say we decide to store the trusted proxies' IPs as "Config:Proxy:SomeName" pages on Meta-Wiki and share this data with the cluster.

If instead you want to dedicate a separate namespace to proxies, the parameters would change to:

Validation
Most of the time one would also want a custom content class with its own validation. JSON pages are handled by the content classes which derive from. The content class is responsible for parsing and validating raw text. does not do any validation beyond JSON parsing, but you may choose to derive from it and override. Better yet, you may derive from the  class which provides a number of validation primitives, and only override.

For the sake of this documentation, let's presume that the proxy config page describing Opera Mini servers has this format:

Here is the content class to validate that data.

Personnaliser le comportement sur le wiki de stockage
You may also want to customize viewing and page creation on the storage wiki (Meta-Wiki in the above example). There are two ways to do this: inside your -derived class, or via a separate "view" class that derives from. The second approach is preferable as it cleanly separates the architecture and the view class need only exist in the storage wiki (e.g. Meta-Wiki), not on all the wikis that use the data.

To override default value in -derived class, override the constructor and set the   value to the new default if it came in as NULL before passing it to the parent constructor. To override the HTML generation, override.

With the recommended way, create a view class that derives from  or a more feature-rich. For, you will need to implement   and. By default, the view is implemented by the  class, which can also be used as a customizable base if you just need minor adjustments to the way it looks.

Meilleures pratiques

 * Les extensions qui utilisent JsonConfig doivent ajouter leurs configurations à  et à   dans le fichier principal de l'extension.
 * Si vous partagez des données de configuration à travers plusieurs wikis, renseignez le nom de clé utilisé dans, et initialisez la section 'store' / 'remote' de  . C'est mieux que d'introduire un nombre de variables globales qui double la fonction des paramètres. Voir par exemple les paramètres Wikimedia de l'extension Graph pour plusieurs wikis (bien qu'elle utilise une configuration complexe multi-wiki plutôt que de simples variables de configuration).

Fonctionnalités implémentées

 * L' analyse syntaxique JSON convertit le texte JSON soit en tableau soit en objet.
 * La visualisation affiche le JSON sous forme de table facile à visualiser plutôt que le code, avec quelques mises en valeur supplémentaires. Par exemple si la valeur n'est pas fournie et qu'une valeur par défaut est utilisée, l'affichage est en gris, et lorsque la valeur est la même que celle par défaut, alors l'affichage est en violet. Pour les exemples, voir ici et ici.
 * L' éditeur de code simplifie l'édition JSON
 * la validation utilisateur réalise des contrôles complexes tels que vérifier que la valeur est au bon format ou bien que l'ID d'un utilisatuer existe bien.
 * la mise en cache mémoire enregistre les blobs JSON dans le cache mémoire sous des clés personnalisées et des règles d'expiration, et les réinitialise à l'enregistrement.
 * la prise en charge du marquage des révisions autorise de marquer les configurations « a été revu » (reviewed) avant de passer en production
 * la traduction de la plupart des éléments d'interface de base a été faite en plusieurs langues, et cela réduirait le travail de traduction si la plupart des messages communs étaient traduits et centralisés en un même endroit.

Fonctionnalités non implémentées mais bienvenues
Ces fonctionnalités sont souhaitables pour plus d'un type de configurations :
 * le valideur de schéma - valide le schéma JSON, étant donné que la plupart des extensions ne nécessitent pas de règles de validation complexes, ou si elles auraient besoin de combiner la validation du schéma et des règles supplémentaires.
 * l' éditeur personnalisé - l'équipe zéro pense à implémenter un éditeur plus complexe, événtuellement basé sur le schéma JSON.
 * la prise en charge de l' API de requête - elle permet de recevoir les pages de configuration en tant que résultats réguliers d'API dans tous les formats - json/xml/... au lieu de blobs textuels :
 * la localisation - il serait utile de pouvoir afficher les descriptions traduites pour chaque clé de configuration.
 * la localisation - il serait utile de pouvoir afficher les descriptions traduites pour chaque clé de configuration.

Liens externes
Les données de configuration enregistrées peuvent souvent être nécessaires à un agent externe quelconque tel que du JavaScript, un robot ou d'autres programmes. Le JavaScript peut utiliser soit JSONP pour accéder aux données nécessaires en appelant l'API standard, ou nous pouvons développer un service de retransmission si CORS n'est pas disponible. Les auteurs d'extensions peuvent choisir d'ajouter leur propres modules d'API pour fournir les informations spécifiques au domaine. Enfin, le paramètre de requête  doit renvoyer les données JSON dans les résultats de l'API, et non pas en tant que blob textuel renvoyé par.