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

 * Vous pouvez utiliser JsonConfig pour stocker les données de plusieurs façons :
 * dans une page de configuration unique, par exemple la liste des paramètres de votre extension de Config:MyExtSettings ( étant l'espace de noms par défaut associé à l'extension JsonConfig);
 * dans un ensemble de pages ayant une structure similaire stockées dans leur propre espace de noms, par exemple les adresses IP des proxy connus ou les schémas des journaux d'événements nommés "Proxy:Opera", ou les schémas nommés Schema:AccountCreation
 * pour l'utiliser simplement pour les pages dont les titres répondent au motif d'une expression régulière, par exemple Config:Proxy:Opera ou Config:Opera.proxy. ce qui évite d'encombrer les wikis avec de multiples espaces de noms, un par modèle de contenu.
 * Vous pouvez fournir une classe de contenu pour faire la validation des données (après le JSON valide) et la normalisation.
 * Vous pouvez fournir une classe de visualisation pour personnaliser l'affichage du HTML.
 * Vous pouvez stocker des données :
 * données par wiki, données par grappe (cluster), ou même données par famille (structure différente de la clé du cache pour le cache mémoire partagé);
 * dans un wiki publique ou privé et accédé à l'aide d'informations personnelles;
 * dans une grappe séparée, en réalisant la notification à distance en cas de modification.

Actuelle

 * Ensembles communs de données de type tableaux
 * Ensembles communs de données de type cartes
 * Configurations de tableaux de bord Dashiki
 * Autres ?

Précédente

 * Configurations opérateur de Wikipedia Zero (voir 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
Le cas le plus simple est une page de paramètres unique sans aucune validation stockée localement sur chaque wiki. Ajoutez simplement ces déclarations à 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. Vous pouvez stocker dans la page, des données JSON correctement formatées.

Pour

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
Souvent on souhaite aussi avoir une classe de contenu personnalisée avec sa propre validation. Les pages JSON sont gérées par les classes de contenu qui dérivent de. La classe de contenu est responsable de l'analyse syntaxique et de la validation du texte brut. ne fait aucune validation au-delà de l'analyse JSON, mais vous pouvez choisir d'en dériver et de redéfinir. Encore mieux, vous pouvez dériver la classe  qui fournit un nombre de primitives de validation, et redéfinir seulement.

Grâce à cette documentation, supposons que la page de configuration du proxy qui décrit les serveurs Opera Mini possède ces formats :

Voici la classe de contenu pour valider ces données.

Personnaliser le comportement sur le wiki de stockage
Vous pouvez aussi personnaliser l'affichage et la création de page sur le wiki de stockage (Meta-Wiki dans l'exemple ci-dessus). Deux moyens pour faire cela : soit dans votre classe dérivée de , soit par une classe « view » séparée qui dérive de. La seconde approche est préférable car elle sépare clairement l'architecture, et la classe de visualisation n'a besoin d'exister uniquement que sur le wiki de stockage (c'est à dire Meta-Wiki) et non pas sur tous les wikis qui utilisent les données.

Pour redéfinir la valeur par défaut dans la classe dérivée de, redéfinissez le constructeur et initialisez la valeur   avec la nouvelle valeur par défaut si la valeur d'entrée est NULL, avant de la passer au constructeur du parent. Pour substituer la génération du HTML, réécrasez.

En suivant la méthode recommandée, créez une classe de visualisation qui dérive de  ou d'une classe avec plus de fonctionnalités. Pour, vous devrez implémenter   et. Par défaut, la vue est implémentée par la classe, qui peut aussi être utilisée comme base personnalisable si vous avez besoin simplement d'ajustements mineurs concernant l'apparence.

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.