CFG multi : didacticiel

Exemple d’utilisation de la méthode « multi » du plugin CFG...

Petit didacticiel (tutoriel) illustrant pas à pas l’utilisation de la méthode « multi » du plugin CFG...

Avant-Propos

Bonjour à tous :-)

Pour des besoins personnels, j’ai récemment entrepris d’explorer quelque peu le plugin CFG, conçu et réalisé par notre regretté ami Toggg [1].

Suite à quelques échanges sur la liste de discussion de Spip-Zone, il s’avère que certaines fonctionnalités du plugin CFG restent encore méconnues, surtout par manque de documentation. « L’ailleurs » l’ayant appelé hélas trop tôt, Toggg n’a pas eu le temps de la compléter.

Répondant donc à plusieurs demandes, j’ai accepté de faire un petit article afin de partager ici quelque unes de mes découvertes, notamment en ce qui concerne la méthode « multi » de CFG.

Ce didacticiel n’est donc qu’un complément aux autres excellents articles déjà parus sur SPIP-Contrib à propos de CFG :

-  Coder un plugin simple avec cfg ;
-  Cfg : références.

Introduction

CFG est l’un des plugins les plus populaires aujourd’hui, il suffit d’apprécier la liste des autres contributions qui l’utilisent pour s’en convaincre.

Il est né de la nécessité de disposer d’un système de configurations souple et simple d’emploi pour les plugins et squelettes.

Qui dit « configuration », dit besoin de mémoriser un certain nombre d’informations pour pouvoir les utiliser par la suite, pour, par exemple, régler le comportement d’un plugin, conditionner l’affichage d’une partie de squelette, ou, pourquoi pas, sauvegarder puis afficher des données non traitées par défaut par SPIP [2]. C’est à partir de cette dernière utilisation que nous allons explorer quelques particuliarités de CFG.

En règle générale, une seule page de configuration suffit pour régler les options nécessaires au fonctionnement d’un plugin, mais qu’en est-il si nous souhaitons mémoriser la configuration de plusieurs éléments de même nature ?

Parmi ses nombreuses fonctionnalités, CFG en propose une particulièrement adaptée à la configuration de plusieurs éléments ayant tous les mêmes types de données à mémoriser. Il s’agit de la méthode « multi » [3].

C’est donc cette méthode « multi » que nous tenterons d’étudier dans cet article.

Important !

Ce didacticiel ou tutoriel ne doit en aucun cas être considéré comme une source documentaire de référence, mais plutôt comme un simple exercice pratique d’utilisation d’une des fonctionnalités méconnues de CFG.

Avertissement !

Cet article est relativement long, car il tente d’aborder le sujet de manière à être le plus accéssible possible à la plupart des utilisateurs de SPIP. L’approche progressive retenue et l’effort d’explication des différentes notions abordées, parfois de manière un peu redondante, cherchent à rendre le sujet le plus clair possible, même si on peut déplorer fatalement quelques lourdeurs et longueurs.

Cependant, pour ne pas vous imposer une lecture fastidieuse, si vous êtes déjà familier avec les langages Web comme le Html, le JavaScript et que vous êtes à l’aise avec la syntaxe des boucles de SPIP, vous n’aurez certainement pas besoin de lire l’article in extenso, surtout la partie de conception et réalisation du formulaire de configuration, je vous propose donc deux possibilités pour optimiser votre lécture :

  • Si vous n’avez jamais utilisé CFG, ou très peu, je vous invite à commencer votre lecture par le chapitre « Utilisation du Formulaire CFG » ;
  • Si vous connaissez déjà CFG, je vous propose de vous rendre directement aux chapitres « CFG multi : Fonctionnement » et suivants.

Bonne lecture...

Le Scénario

Pour mieux illustrer dans quel type de situations cette méthode « multi » de CFG peut s’avérer utile, et surtout fort pratique, plantons un décor quelque peu imaginaire mais tout-à-fait plausible :

  • Supposons que nous participons, en tant que responsables et auteurs, à l’animation d’un site spécialisé dans la publication d’articles de vulgarisation de différentes technologies Web ;
  • Supposons aussi que ce site compte déjà avec la participation de plusieurs autres auteurs ;
  • Supposons maintenant que, pour des besoins d’information auprès des lecteurs, afin de répondre à des nombreuses demandes, on souhaite afficher, sur la page d’infos de chaque auteur (fichier « auteur.html » de SPIP), leurs niveaux de compétence ou qualification dans les différentes technologies Web traitées sur le site ;
  • Supposons enfin que, pour des raisons d’impartialité et d’un minimum d’objectivité, ces infos ne puissent être gérées que par les responsables du site.

Voilà pour le contexte.

Bien-sûr, une manière simple de résoudre cette situation, serait d’utiliser le champ « Biographie » de la page « Informations personnelles » de chaque auteur, a priori tout-à-fait indiquée à recevoir de telles infos.

Mais, ce champ restant accessible et modifiable par chaque auteur, les responsables du site ne pourraient pas garantir l’impartialité et objectivité nécessaires pour répondre aux attentes des lecteurs.

Alors, aurait-il une autre solution ?

Peut-être que la plus simple des solutions alternatives c’est CFG qui la propose, grâce à sa méthode « multi ».

En effet, étant donnée que nous souhaitons mémoriser le même type d’informations, et le même nombre en l’occurrence, pour chacun des auteurs du site, cette méthode permet d’utiliser un seul et unique fichier de configuration pour tous les auteurs.

Nous allons donc réaliser, dans les chapitres suivants, une page de configuration (formulaire CFG) afin de pouvoir mémoriser ces informations, puis nous allons voir comment fonctionne la méthode « multi », enfin, nous verrons comment récupérer les données sauvegardées pour les afficher sur la page « Auteur » de l’espace publique.

Note !

La réalisation de la page de configuration sera décomposée en plusieurs étapes, ceci afin d’avancer de manière progressive et de ne pas risquer de vous décourager avec des codes complexes dès le début. Le revers de la médaille avec cette formule, est que l’article devient fatalement plus long, mais je pense que cette façon de procéder, par étapes successives, permettra une meilleur clarté des notions abordées.

Important !

Nous n’allons pas réaliser un plugin ici, ceci a été largement expliqué dans l’article Coder un plugin simple avec cfg, nous allons juste nous contenter de placer notre fichier Html de configuration dans le squelette actif de notre site.

Le Fichier Html de Configuration

Nous allons donc créer, dans ce chapitre, un fichier Html de configuration, qui contiendra le formulaire CFG qui servira à mémoriser les infos de qualifications techniques de chaque auteur.

Important !

Avant tout, assurez-vous d’avoir, installée et active, la dernière version en date du plugin CFG. Pour récupérer la dernière version, rendez-vous à l’espace de téléchargement de la Spip-Zone. Ce didacticiel à été réalisé avec la version 1.0.10 de CFG, datant du 30 septembre 2007, puis testée sous Spip 1.9.2c.

Pour créer notre fichier de configuration, commençons donc par créer un répertoire nommé « fonds » (en minuscules et au pluriel) à la racine de notre dossier « squelettes » (ou dans le dossier « dist » si vous utilisez le squelette par défaut distribué avec Spip).

Ensuite, dans ce dossier « fonds », créons un fichier Html nommé « cfg_qualif.html ».

Le nom de ce fichier est donc composé d’un préfixe « cfg_ », absolument nécessaire pour que le plugin puisse le reconnaître comme étant un fichier de configuration, suivi du terme « qualif », abréviation courante de « qualifications », puis l’extension « .html » usuelle.

Nous verrons plus loin que le nom du fichier, c’est-à-dire « qualif » en l’occurrence, aura un rôle important pour bénéficier de certaines fonctionnalités avancées de CFG et de la méthode « multi ».

Éditons donc ce fichier « cfg_qualif.html » et concentrons-nous sur la conception et la réalisation du formulaire CFG.

Le Formulaire CFG : 1. Structure

La première étape dans la réalisation du formulaire consiste à imaginer sa structure.

Le formulaire sera divisé en 5 parties aux rôles bien distincts :

  • Partie 1 : Paramètres CFG.
    Contiendra les différentes balises « #REM » de paramétrage de CFG ;
  • Partie 2 : Auteurs.
    Contiendra la liste des auteurs enregistrés sur le site ;
  • Partie 3 : Configuration.
    Contiendra l’identifiant unique de la configuration affichée ou à mémoriser, ainsi qu’une option permettant de créer une nouvelle configuration à partir d’un identifiant modifié ;
  • Partie 4 : Niveaux de qualification.
    Contiendra les différents champs pour noter le niveau de qualification Web de l’auteur affiché ou à mémoriser ;
  • Partie 5 : Boutons de validation.
    Contiendra les boutons d’enregistrement et suppression de la configuration affichée, ainsi que le bouton d’annulation du formulaire.

Voici à quoi ressemble cette structure :

Et voici le code de cette première étape (qui n’a pas grande utilité pour l’instant, si ce n’est que de visualiser le « squelette » de notre formulaire) :

<!-- Partie 1 : Parametres CFG -->
[(#REM) titre=Qualification Auteurs]
#CACHE{0}

<form method="post">[(#ENV{_cfg_}|form_hidden)]

<!-- Partie 2 : Auteurs -->
<fieldset><legend>Auteurs</legend>
<label>Liste des auteurs</label>
</fieldset>

<!-- Partie 3 : Configuration -->
<fieldset><legend>Configuration</legend>
<label>Identifiant de la configuration</label>
</fieldset>

<!-- Partie 4 : Niveaux de qualification -->
<fieldset><legend>Niveaux de qualification de l'auteur</legend>
<label>Champs pour noter le niveau de qualification de l'auteur à mémoriser</label>
</fieldset>

<!-- Partie 5 : Boutons de validation -->
<label>Boutons de validation du formulaire</label>

</form>

Petite explication :

  • Le code [(#REM) titre=Qualification Auteurs] est un paramétre CFG, il correspond au titre qui sera affiché sur la fenêtre du navigateur et le titre de l’onglet qui sera affiché sur la page « Configuration des modules » de CFG, dans l’espace privé, c’est à dire :
  • Ensuite le code #CACHE{0} est nécessaire pour que Spip ne sauvegarde pas ce fichier en cache, ce qui permet de calculer le formulaire et son contenu à chaque rechargement de la page.
  • Le code <form method="post">[(#ENV{_cfg_}|form_hidden)] est la méthode « standard » de création de formulaires de CFG, il se charge, notamment, d’insérer automatiquement les champs invisibles nécessaires à l’enregistrement des données.

Enfin, la reste est relativement classique, puisqu’il ne s’agit après-tout que d’un simple formulaire Html, dont nous verrons quelques particularités concernant CFG dans la prochaine étape.

Le Formulaire CFG : 2. Construction

Nous avons donc la structure de base de notre formulaire, attachons-nous maintenant à le construire, en plaçant l’ensemble des champs et boutons nécessaires à l’enregistrement des données.

-  Partie 1 : Paramètres CFG

Commençons par ajouter deux paramètres supplémentaires dans la première partie de notre formulaire :

<!-- Partie 1 : Parametres CFG -->
[(#REM) titre=Qualification Auteurs]
[(#REM) descriptif=<h4>Utilisation de la méthode Multi de Cfg</h4>]
[(#REM) liens*=qualif]

Petite explication :

  • La balise [(#REM) descriptif=<h4>Utilisation de la méthode Multi de Cfg</h4>] se charge d’afficher un petit descriptif [4] sur la colonne de gauche du formulaire, ce qui donne :
  • La balise [(#REM) liens*=qualif] est un lien direct vers le fichier de configuration lui-même, et qui a la particularité d’activer une option fort intéressante et utile, uniquement disponible avec cette méthode « multi ».

Nous verrons plus loin, dans le chapitre concernant l’utilisation du formulaire, ces particularités de CFG.

-  Partie 2 : Auteurs

Ensuite, dans la 2e partie de notre formulaire, nous allons afficher un menu déroulant de type <select>...</select> avec la liste des auteurs du site.

Pour ce faire, rien de plus simple (du moins pour les habitués du langage des boucles de Spip), il suffit de faire une petite boucle de type « AUTEURS », puis de récupérer les infos nécessaires.

Voici une première version de ce code :

<!-- Partie 2 : Auteurs -->
<fieldset><legend>Auteurs</legend>
<label>Auteur : </label>
<select onMouseUp="this.form.id.value = this.options[this.selectedIndex].value;">
<BOUCLE_auteurs(AUTEURS){tout}{par id_auteur}>
	<option value="#ID_AUTEUR" [(#ENV{id}|=={#ID_AUTEUR}|?{selected="selected"})]>#LOGIN</option>
</BOUCLE_auteurs>
</select>
</fieldset>

Donc, rien de bien sorcier, seuls points qui ne sont pas très explicites pour l’instant, c’est sont le code JavaScript onMouseUp et le code #ENV{id}, nous verrons plus loin leur utilité.

-  Partie 3 : Configuration

Passons à la 3e partie du formulaire, où nous allons placer un champ de type « text » qui recevra l’identifiant de la configuration, puis un bouton permettant d’afficher la configuration correspondante à l’identifiant utilisé, enfin, une case à cocher permettant de mémoriser une nouvelle configuration si la valeur de l’identifiant a été modifiée.

Ce champ « Id » est peut-être l’un des plus importants de ce type de formulaires, puisque l’ensemble de la méthode « multi » repose sur lui.

En effet, CFG va utiliser la valeur entrée dans ce champ pour créer un « casier » spécialement dédié à contenir les infos de la configuration de l’auteur sélectionné.

En fait, CFG mémorise toutes les informations dans une entrée spécifique de la table « spip_meta » de la base de données de Spip. Cette entrée porte le nom, par défaut, du fichier de configuration (sans le préfixe ni l’extension), « qualif » dans notre cas.

Pour pouvoir hiérachiser les données et ainsi sauvegarder plusieurs configurations dans la même entrée « spip_meta », CFG utilise un sytème de « casiers » [5] mémorisés avec une clé d’identification, et c’est justement cette clé qui est renseignée dans ce champ « Id ».

Pour présenter les choses autrement, nous pouvons illustrer la manière dont CFG va enregistrer les configurations dans la base de données, par une structure hiérarchique à deux niveau :

  • qualif
    • auteur 1
      • info 1
      • info 2
      • info 3
    • auteur 2
      • info 1
      • info 2
      • info 3
    • etc.

Explication :

  • L’élément « qualif » est le nom de l’entrée « spip_meta » crée par CFG dans la base de données, et dans laquelle les configuration seront mémorisées.
  • Les différents « auteur N » sont les fameux « casiers » qui vont contenir chacun les infos de chaque auteur, la configuration en somme. Ces « casiers » seront crées automatiquement par CFG avec la valeur entrée dans le champ « Id » grâce à la présence d’un attribut spécial class="cfg_id" (voir les explications plus bas).
  • Enfin, les « info N » ce sont les informations mémorisées et c’est en définitive ces données qui seront ensuite récupérées et affichées sur la page « auteur.html ».

Voici donc le code de cette partie :

<!-- Partie 3 : Configuration -->
<fieldset><legend>Configuration</legend>
[(#REM) la classe cfg_id permet de stocker dans un tableau sous cet index]
<label>Id : </label><input type="text" name="id" class="cfg_id" id="id" value="#ENV{id}" /> 
<input type="submit" name="_cfg_affiche" value="Afficher" /><br />
<label>Nouvelle config si Id modifié </label><input type="checkbox" name="_cfg_copier" />
</fieldset>

Quelques points importants à retenir de ce code :

  • Le bouton « Afficher », qui sert donc à afficher la configuration de l’auteur choisi, dispose d’un attribut « id » qui est surtout utile pour recevoir les données issues du menu déroulant de la liste des auteurs (2e partie), c’est d’ailleurs le rôle du JavaScript onMouseUp attaché à ce menu.
  • Le code #ENV{id} du menu auteurs, comme celui de ce bouton « Afficher », sert à récupérer dynamiquement, grâce aux variables d’environnement, la valeur correspondante issue la base de données (tout ce mécanisme est géré par CFG).
  • L’attribut class="cfg_id" est l’élément principal de ce formulaire, puisque c’est lui le déclencheur de la méthode « multi ». En effet, c’est sa présence qui signale à CFG la manière de mémoriser les données dans la base de données, et c’est justement la valeur contenue par l’objet où il se trouve, qui sera utilisée par CFG comme identifiant lors de la création des différents « casiers » d’enregistrement des configurations.
  • L’attribut name="_cfg_affiche" placé dans un objet « input », de type « submit », indique à CFG de lancer une réactualisation de la page avec passage, dans les variables d’environnement, de la valeur du champ ayant l’attribut class="cfg_id", ce qui permet de récupérer les valeurs mémorisées dans la base correspondants à cet identifiant.

Important !

L’attribut name="_cfg_affiche" ne doit pas être modifié, sous peine d’annuler cette fonctionnalité.

-  Partie 4 : Niveaux de qualification

La 4e partie du formulaire concerne les différents champs de configuration avec les informations à mémoriser, c’est-à-dire, les valeurs de « qualification technique » de chaque auteur.

Pour ce projet, nous allons utiliser 7 champs correspondants aux langages suivants :
-  html ;
-  css = Cascading Style Sheets ;
-  js = JavaScript ;
-  ajax = Asynchronous JavaScript and XML ;
-  asp = Active Server Pages ;
-  php
-  spip = Système de publication pour l’internet p ? [6]

Évidemment, vous pouvez adapter cette partie du formulaire avec d’autres champs, suivant les informations que vous souhaitez mémoriser pour chaque auteur, ici, continuant avec notre exemple, nous avons choisi quelques technologies Web parmi les plus connues et utilisées.

Voici donc le code :

<!-- Partie 4 : Niveaux de qualification -->
<fieldset><legend>Niveaux de qualification de l'auteur</legend>
<label>Html : </label><input type="text" name="html" value="#ENV{html}" /><br />
<label>Css : </label><input type="text" name="css" value="#ENV{css}" /><br />
<label>Js : </label><input type="text" name="js" value="#ENV{js}" /><br />
<label>Ajax : </label><input type="text" name="ajax" value="#ENV{ajax}" /><br />
<label>Asp : </label><input type="text" name="asp" value="#ENV{asp}" /><br />
<label>Php : </label><input type="text" name="php" value="#ENV{php}" /><br />
<label>Spip : </label><input type="text" name="spip" value="#ENV{spip}" />
</fieldset>

Pas grand chose à signaler sur ce code, sinon que la valeur de chaque objet « input », value="#ENV{xxx}", est dynamiquement récupérée depuis les variables d’environnement, afin d’afficher les bonnes valeurs issues de la base de données, suivant l’identifiant indiqué ou l’auteur choisi.

-  Partie 5 : Boutons de validation

Enfin, la 5e et dernière partie de notre formulaire :

<!-- Partie 5 : Boutons de validation -->
<input type="submit" name="_cfg_delete" value="Supprimer" />
<input type="reset" value="Annuler" />
<input type="submit" name="_cfg_ok" value="Enregistrer" />

Ce sont les boutons par défaut fournis par CFG dans tous ses exemples (voir dans le répertoire « plugins/cfg/fonds/ »).

Seules petites différences ici, leur positionnement relatif et leurs valeurs, modifiés pour obtenir quelque chose d’un peu plus clair et, à mon avis, ergonomique.

Important !

Les attributs name="_cfg_delete" et name="_cfg_ok" sont absolument nécessaires à CFG, et ne doivent en aucun cas être modifiés, sous peine de dysfonctionnements du plugin.

Après toutes ces modifications, voici à quoi ressemble désormais notre formulaire :

Et voici son code complet :

<!-- Partie 1 : Parametres CFG -->
[(#REM) titre=Qualification Auteurs]
[(#REM) descriptif=<h4>Utilisation de la méthode Multi de Cfg</h4>]
[(#REM) liens*=qualif]
#CACHE{0}

<form method="post">[(#ENV{_cfg_}|form_hidden)]

<!-- Partie 2 : Auteurs -->
<fieldset><legend>Auteurs</legend>
<label>Auteur : </label>
<select onMouseUp="this.form.id.value = this.options[this.selectedIndex].value;">
<BOUCLE_auteurs(AUTEURS){tout}{par id_auteur}>
	<option value="#ID_AUTEUR" [(#ENV{id}|=={#ID_AUTEUR}|?{selected="selected"})]>#LOGIN</option>
</BOUCLE_auteurs>
</select>
</fieldset>

<!-- Partie 3 : Configuration -->
<fieldset><legend>Configuration</legend>
[(#REM) la classe cfg_id permet de stocker dans un tableau sous cet index]
<label>Id : </label><input type="text" name="id" class="cfg_id" id="id" value="#ENV{id}" /> 
<input type="submit" name="_cfg_affiche" value="Afficher" /><br />
<label>Nouvelle config si Id modifié </label><input type="checkbox" name="_cfg_copier" />
</fieldset>

<!-- Partie 4 : Niveaux de qualification -->
<fieldset><legend>Niveaux de qualification de l'auteur</legend>
<label>Html : </label><input type="text" name="html" value="#ENV{html}" /><br />
<label>Css : </label><input type="text" name="css" value="#ENV{css}" /><br />
<label>Js : </label><input type="text" name="js" value="#ENV{js}" /><br />
<label>Ajax : </label><input type="text" name="ajax" value="#ENV{ajax}" /><br />
<label>Asp : </label><input type="text" name="asp" value="#ENV{asp}" /><br />
<label>Php : </label><input type="text" name="php" value="#ENV{php}" /><br />
<label>Spip : </label><input type="text" name="spip" value="#ENV{spip}" />
</fieldset>

<!-- Partie 5 : Boutons de validation -->
<input type="submit" name="_cfg_delete" value="Supprimer" />
<input type="reset" value="Annuler" />
<input type="submit" name="_cfg_ok" value="Enregistrer" />

</form>

Le Formulaire CFG : 3. Mise en Forme

Voilà, notre formulaire est bien avancé, si nous le souhaitons, nous pouvons d’ors et déjà l’utiliser pour mémoriser des configurations et utiliser les valeurs enregistrées dans la page « auteur.html » du squelette. Le mécanisme de base nécessaire à CFG est déjà en place, mais, avant de commencer à l’utiliser, je vous propose d’améliorer un peu la mise en forme du formulaire, car, avouons-le, son aspect actuel n’est pas bien zoli-zoli ;-)

-  Partie 1 : Paramètres CFG

Dans cette étape nous n’allons rien changer à cette première partie du code.

-  Partie 2 : Auteurs

Passons donc directement à la 2e partie.

Jusqu’à là nous utilisions uniquement le "#ID_AUTEUR" comme valeur de sauvegarde des « casiers » de la méthode « multi ».

Ceci fonctionne bien, mais dans un souci de plus de clarté, nous verrons plus loin l’utilité, nous allons ajouter le "#LOGIN" de l’auteur, afin d’avoir des « casiers » avec des noms plus parlants, ce qui va nous donner : "#ID_AUTEUR-#LOGIN".

Côté mise en page, nous allons utiliser des tableaux pour assurer une présentation un peu plus « propre » et claire de l’interface, avec quelques styles « en ligne » pour formater précisément la taille de certains éléments. Nous utiliserons ensuite ces mêmes styles sur les tableaux des autres parties du code, afin d’avoir une présentation plus cohérente de l’ensemble du formulaire.

Voici donc le code un peu amélioré de cette 2e partie :

<!-- Partie 2 : Auteurs -->
<fieldset><legend>Auteurs</legend>
<table><tr>
<td style="width: 60px"><label>Auteur : </label></td>
<td><select onMouseUp="this.form.id.value = this.options[this.selectedIndex].value;" style="width: 120px;">
<BOUCLE_auteurs(AUTEURS){tout}{par id_auteur}>
	<option value="#ID_AUTEUR-#LOGIN" [(#ENV{id}|=={#ID_AUTEUR-#LOGIN}|?{selected="selected"})]>#ID_AUTEUR-#LOGIN</option>
</BOUCLE_auteurs>
</select></td>
</tr></table>
</fieldset>

-  Partie 3 : Configuration

La 3e partie du code n’aura pas de changements majeurs, juste quelques modifications afin d’adopter une présentation avec des tableaux suivant ce que nous avons fait dans la 2e partie.

On en profite aussi pour donner un « label » plus parlant à la case à cocher qui crée une nouvelle configuration si l’identifiant a été modifié.

Donc, voici le code :

<!-- Partie 3 : Configuration -->
<fieldset><legend>Configuration</legend>
[(#REM) la classe cfg_id permet de stocker dans un tableau sous cet index]
<table><tr>
<td style="width: 60px"><label>Id : </label></td><td><input type="text" name="id" class="cfg_id" id="id" value="#ENV{id}" style="width: 120px;" />
 | <input type="submit" name="_cfg_affiche" value="Afficher" style="width: 80px;" /></td>
</tr><tr>
<td style="width: 60px"><label>Option : </label></td><td><input type="checkbox" name="_cfg_copier" /><label> Enregistrer une nouvelle configuration si "Id" modifié</label></td>
</tr></table>
</fieldset>

-  Partie 4 : Niveaux de qualification

Dans cette 4e partie du code, nous allons aussi, bien-sûr, améliorer la présentation des champs avec toujours des tableaux.

De plus, nous allons définir le type de notation que nous voulons utiliser, pour éviter ou limiter que chacun inscrive des valeurs trop différentes dans chaque champ de qualificaton.

Nous allons donc ajouter une petite note en bas de cette partie en indiquant clairement quelles sont les valeurs permises et/ou souhaitées.

Pour simplifier la notation, puis l’affichage de qualifications, nous allons utiliser un système d’appréciation avec des étoiles (astérisques), sur seulement 4 niveaux de compétences :

  • Vide = aucune qualification ;
  • * = Pratiquant ;
  • ** = Confirmé ;
  • *** = Expert.

Voici donc le code amélioré de cette 4e partie :

<!-- Partie 4 : Niveaux de qualification -->
<fieldset><legend>Niveaux de qualification de l'auteur</legend>
<table><tr>
<td style="width: 60px"><label>Html : </label></td><td style="width: 140px"><input type="text" name="html" value="#ENV{html}" size="10" /></td>
<td style="width: 60px"><label>Css : </label></td><td style="width: 140px"><input type="text" name="css" value="#ENV{css}" size="10" /></td>
</tr><tr>
<td style="width: 60px"><label>Js : </label></td><td style="width: 140px"><input type="text" name="js" value="#ENV{js}" size="10" /></td>
<td style="width: 60px"><label>Ajax : </label></td><td style="width: 140px"><input type="text" name="ajax" value="#ENV{ajax}" size="10" /></td>
</tr><tr>
<td style="width: 60px"><label>Asp : </label></td><td style="width: 140px"><input type="text" name="asp" value="#ENV{asp}" size="10" /></td>
<td style="width: 60px"><label>Php : </label></td><td style="width: 140px"><input type="text" name="php" value="#ENV{php}" size="10" /></td>
</tr><tr>
<td style="width: 60px"><label>Spip : </label></td><td style="width: 140px"><input type="text" name="spip" value="#ENV{spip}" size="10" /></td>
</tr></table>
<small><em>Note : vide = aucune qualification, * = pratiquant, ** = confirmé, *** = expert.</em></small>
</fieldset>

-  Partie 5 : Boutons de validation

Enfin, la 5e partie ne bénéficie que de petites modifications de taille et de positionnement, surtout pour améliorer un peu l’accès au bouton « Enregistrer » et éviter ainsi les « fausses maneuvres » avec les boutons « Annuler » et « Supprimer ». Voici le code :

<!-- Partie 5 : Boutons de validation -->
<div>
<input type="submit" name="_cfg_delete" value="Supprimer" style="width: 80px;" /> | 
<input type="reset" value="Annuler" style="width: 80px;" />
<input type="submit" name="_cfg_ok" value="Enregistrer" style="width: 120px; float: right;" />
</div>

Voyons donc à quoi ressemble maintenant notre formulaire :

Et voci le code complet :

<!-- Partie 1 : Parametres CFG -->
[(#REM) titre=Qualification Auteurs]
[(#REM) descriptif=<h4>Utilisation de la méthode Multi de Cfg</h4>]
[(#REM) liens*=qualif]
#CACHE{0}

<form method="post">[(#ENV{_cfg_}|form_hidden)]

<!-- Partie 2 : Auteurs -->
<fieldset><legend>Auteurs</legend>
<table><tr>
<td style="width: 60px"><label>Auteur : </label></td>
<td><select onMouseUp="this.form.id.value = this.options[this.selectedIndex].value;" style="width: 120px;">
<BOUCLE_auteurs(AUTEURS){tout}{par id_auteur}>
	<option value="#ID_AUTEUR-#LOGIN" [(#ENV{id}|=={#ID_AUTEUR-#LOGIN}|?{selected="selected"})]>#ID_AUTEUR-#LOGIN</option>
</BOUCLE_auteurs>
</select></td>
</tr></table>
</fieldset>

<!-- Partie 3 : Configuration -->
<fieldset><legend>Configuration</legend>
[(#REM) la classe cfg_id permet de stocker dans un tableau sous cet index]
<table><tr>
<td style="width: 60px"><label>Id : </label></td><td><input type="text" name="id" class="cfg_id" id="id" value="#ENV{id}" style="width: 120px;" />
 | <input type="submit" name="_cfg_affiche" value="Afficher" style="width: 80px;" /></td>
</tr><tr>
<td style="width: 60px"><label>Option : </label></td><td><input type="checkbox" name="_cfg_copier" /><label> Enregistrer une nouvelle configuration si "Id" modifié</label></td>
</tr></table>
</fieldset>

<!-- Partie 4 : Niveaux de qualification -->
<fieldset><legend>Niveaux de qualification de l'auteur</legend>
<table><tr>
<td style="width: 60px"><label>Html : </label></td><td style="width: 140px"><input type="text" name="html" value="#ENV{html}" size="10" /></td>
<td style="width: 60px"><label>Css : </label></td><td style="width: 140px"><input type="text" name="css" value="#ENV{css}" size="10" /></td>
</tr><tr>
<td style="width: 60px"><label>Js : </label></td><td style="width: 140px"><input type="text" name="js" value="#ENV{js}" size="10" /></td>
<td style="width: 60px"><label>Ajax : </label></td><td style="width: 140px"><input type="text" name="ajax" value="#ENV{ajax}" size="10" /></td>
</tr><tr>
<td style="width: 60px"><label>Asp : </label></td><td style="width: 140px"><input type="text" name="asp" value="#ENV{asp}" size="10" /></td>
<td style="width: 60px"><label>Php : </label></td><td style="width: 140px"><input type="text" name="php" value="#ENV{php}" size="10" /></td>
</tr><tr>
<td style="width: 60px"><label>Spip : </label></td><td style="width: 140px"><input type="text" name="spip" value="#ENV{spip}" size="10" /></td>
</tr></table>
<small><em>Note : vide = aucune qualification, * = pratiquant, ** = confirmé, *** = expert.</em></small>
</fieldset>

<!-- Partie 5 : Boutons de validation -->
<div>
<input type="submit" name="_cfg_delete" value="Supprimer" style="width: 80px;" /> | 
<input type="reset" value="Annuler" style="width: 80px;" />
<input type="submit" name="_cfg_ok" value="Enregistrer" style="width: 120px; float: right;" />
</div>
</form>

Le Formulaire CFG : 4. Fignolages

Notre formulaire est fin-près, nous pouvons commencer à l’utiliser en l’état.

Seulement, puisque nous sommes dans le chapitre des « fingnolages », profitons pour imaginer une solution qui limite les valeurs à entrer dans les champs de saisie des qualifications. En effet, malgré notre petite note en bas de la 4e partie, rien n’interdit qu’on entre d’autres valeurs dans les champs des qualifications.

Nous pourrions utiliser une fonction JavaScript pour vérifier le contenu de ces champs avant de mémoriser la configuration, mais avant de sortir la grosse artillérie, je pense que dans notre exemple le plus simple serait de remplacer les champs de saisie par des menus déroulants avec les valeurs prédéfinies que nous souhaitons proposer.

Voici un exemple de code de ce menu déroulant :

<select name="html" id="html">
	<option value="" [(#ENV{html}|=={''}|?{selected="selected"})]><Aucun></option>
	<option value="*" [(#ENV{html}|=={'*'}|?{selected="selected"})]>Pratiquant</option>
	<option value="**" [(#ENV{html}|=={'**'}|?{selected="selected"})]>Confirmé</option>
	<option value="***" [(#ENV{html}|=={'***'}|?{selected="selected"})]>Expert</option>
</select>

D’autre part, puisque nous sommes à l’étape des petites retouches de dernière minute, profitons-en pour ajouter quelques info-bulles aux éléments importants, afin d’apporter quelques précisions à l’utilisateur.

Dernier détail, CFG propose, depuis peu, la possibilité de visualiser la structure et les données enregistrées dans la base de données, grâce à l’utilisation d’une nouvelle balise « #CFG_ARBO » (assurez-vous d’avoir la dernière version du plugin), nous allons en profiter pour la placer à la fin du formulaire.

Cette balise nous sera utile pendant le temps de développement et de mise au point du fichier de configuration, il n’est pas nécessaire de la laisser dans la version finale du formulaire.

Pour ne pas alourdir inutilement cet article déjà bien long, et qui n’est pas encore fini (loin s’en faut), le code de cette étape ne sera pas publié ici, puisqu’il n’apporte pas de changement essentiel par rapport à l’étpe précédente.

Je vous propose en revanche de trouver cette dernière version du formulaire dans les sources à télécharger en fin d’article.

En attendant, voici à quoi ressemble maintenant notre formulaire :

Utilisation du Formulaire CFG

Voilà, notre formulaire CFG est finalisé, voyons maintenant comment l’utiliser afin de sauvegarder des configurations de « qualification technique » pour chaque auteur du site.

C’est bien à cette étape, lors de l’utilisation du formulaire, que nous allons découvrir tout l’intérêt et la puissance de la méthode « multi » de CFG.

Commençons donc par afficher notre formulaire CFG, suivez le guide :

  • Dans l’espace privé du site, affichons la page principale de configuration en cliquant sur le bouton « Configuration » ;
  • Dans la page qui s’affiche, nous allons découvrir un onglet portant le nom évocateur de « CFG » (si jamais vous le ne voyez pas, vérifiez la bonne installation et activation du plugin) ;
  • En cliquant sur cet onglet « CFG », nous allons afficher l’ensemble des modules gérés par le plugin :
  • Nous devrions donc voir un onglet portant le titre de « Qualification Auteurs », comme ceci :
  • Enfin, cliquons sur cet onglet pour afficher notre formulaire.

Ceux qui ont déjà une expérience d’utilisation du plugin CFG, remarqueront dans la colonne de gauche, un bloc-menu particulier, juste en dessous du cadre affichant le descriptif de notre formulaire.

Ce bloc-menu affiche le nom de notre fichier de configuration (voir chapitre « CFG multi : Fonctionnement » pour plus de détails), à savoir « qualif », puis, juste après, nous trouvons un bouton nommé « nouveau + », qui permet de créer des nouveaux « casiers » de sauvegarde :

Pour le faire apparaître, nous devons insérer la balise de paramètrage [(#REM) liens*=qualif] en tête du formulaire, tel que nous l’avons vu à l’étape 2 de sa construction, cette balise crée un lien direct vers le fichier de configuration lui-même [7].

En plus du bouton « nouveau + », ce bloc-menu propose d’autres fonctionnalités intéressantes. En effet, comme nous l’avons vu plus haut, la méthode « multi » sert essentiellement à mémoriser des configurations multiples utilisant le même formulaire, mais comment savoir quelles sont les configurations déjà mémorisées ?

C’est justement ce bloc-menu qu’est utilisé par CFG pour apporter une solution très pratique... mais pour pouvoir l’apprécier, nous devons commencer par sauvegarder quelques configurations.

Rien de plus simple, supposons que nous avons 3 auteurs sur notre site : Pierre, Paul et Jacques (quelle imagination ! ;-), voici la marche à suivre :

  • Commençons donc par choisir un de ces auteur dans la liste des auteurs du site, admettons qu’on choisi « 3-pierre » en premier [8] ;
  • Dès que notre choix est fait, il vient s’inscrire dans le champ « Id » de la zone « Configuration » de notre formulaire, c’est-à-dire « 3-pierre » dans notre cas. C’est cette valeur qui sera utilisée pour créer le « casier » d’enregistrement de la configuration ;
  • Choisissons maintenant les différentes « qualifications techniques » de cet auteur avec les menus déroulants de chaque technologie Web listée ;
  • Enfin, cliquons sur le bouton « Enregistrer » pour sauvegarder cette configuration dans la table « spip_meta » correspondante ;
  • Dès la sauvegarde faite, CFG va réactualiser l’affichage de la page et nous pourrons alors découvrir, dans le bloc-menu de la colonne de gauche, un lien avec le nom de notre configuration, à savoir « 3-pierre », suivi d’une petite flêche.

Continuons donc en enregistrant une configuration pour chacun de nos deux autres auteurs, nous devrions nous retrouver alors avec un bloc-menu de ce type :

Voilà, vous venez d’apprécier tout l’intérêt et la puissance de la méthode « multi » de CFG, c’est à dire, la possibilité de mémoriser autant de configurations que nécessaires à partir d’un seul et même formulaire, avec affichage automatique des différentes configuratioins sauvegardées.

Voici les points importants à retenir :

  • Chaque configuration sauvegardée est automatiquement listée par CFG dans le bloc-menu de la colonne de gauche, ce qui permet de visualiser rapidement toutes les configurations en mémoire.
  • Un simple clic sur la petite flêche de l’une de ces configurations listées, nous permet d’afficher toutes les infos correspondantes, issues dans la base de données, directement dans le formulaire, grâce à la gestion des variables d’environnement de CFG.
  • Ces configurations mémorisées sont en réalité des « casiers », c’est-à-dire des tableaux de données indépendants mais qui s’enregistrent tous dans la même entrée « spip_meta » de la base de données, à savoir « qualif » dans notre cas.
  • Ces « casiers » sont automatiquements crées par CFG grâce à la présence de l’attribut class="cfg_id" dans un des champs du formulaire, c’est-à-dire le champ « Id » dans notre exemple.
  • Le nom du « casier » est donc la valeur présente dans le champ possédant l’attribut class="cfg_id" au moment de l’enregistrement de la configuration, c’est-à-dire la valeur du champ « Id » dans notre exemple.
  • Enfin, le bouton « nouveau + » permet de créer autant de nouvelles configurations qu’on aurait besoin, même si elles ne correspondent pas à des auteurs existants sur le site.

Cette dernière option peut être utile, dans une certaine mesure, si jamais on désire publier des articles d’auteurs étrangers au site, dont on connait les qualifications techniques par exemple. Nous ne développerons pas d’avantage cette option, vous pourrez découvrir aisément les possibilités qu’elle offre en l’explorant un peu.

Dans le chapitre « CFG multi : Fonctionnement » nous verrons un peu plus en profondeur le mécanisme utilisé par la méthode « multi » de CFG.

Affichage des Configurations

Voyons maintenant comment faire pour afficher les informations mémorisées dans les différentes configurations existantes dans la base de données.

Nous allons donc afficher les « qualifications techniques » des auteurs dans la page dédiée à la présentation de leurs informations, c’est-à-dire le fichier Html nommé « auteur.html » de Spip.

L’exemple illustré ci-après est une version un peu modifiée et largement simplifiée d’un code issu du squelette MiniGriSpip 1.6, mais vous pouvez facilement l’adapter à la plupart des autres squelettes Spip disponibles.

Nous allons placer la balise "#CONFIG" propre à CFG dans une boucle Spip de type « AUTEURS », afin de pouvoir utiliser l’identifiant unique de l’auteur, balise "#ID_AUTEUR", ainsi que son login, balise "#LOGIN", qui nous serviront à composer les identifiants utilisés pour mémoriser les différentes configurations.

Voici donc un premier code d’exemple :

<BOUCLE_auteurs(AUTEURS){id_auteur}>
<div class="mgs_bloc">
	[<div class="mgs_logo">(#LOGO_AUTEUR|right||image_reduire{60})</div>]
	<h2 class="mgs_titre">#NOM</h2>
	<div class="mgs_texte_int">
		[<div class="mgs_texte">(#BIO)</div>]
		[(#CONFIG{qualif/#ID_AUTEUR-#LOGIN}|?{' ',''})
		<div style="margin: 10px auto; padding: 10px; background-color: #f3f3f3; border: 1px solid gray;">
			<h4>Qualification par technologie</h4>
			<p style="margin: 5px; padding: 0px 10px;">
			- Html : #CONFIG{qualif/#ID_AUTEUR-#LOGIN/html}<br />
			- Css : #CONFIG{qualif/#ID_AUTEUR-#LOGIN/css}<br />
			- Js : #CONFIG{qualif/#ID_AUTEUR-#LOGIN/js}<br />
			- Ajax : #CONFIG{qualif/#ID_AUTEUR-#LOGIN/ajax}<br />
			- Asp : #CONFIG{qualif/#ID_AUTEUR-#LOGIN/asp}<br />
			- Php : #CONFIG{qualif/#ID_AUTEUR-#LOGIN/php}<br />
			- Spip : #CONFIG{qualif/#ID_AUTEUR-#LOGIN/spip}
			</p>
			<small>Note : vide = acune qualification, * = pratiquant, ** = confirmé, *** = expert.</small>
		</div>]
		[<p class="mgs_intro">Voir en ligne : <a href="(#URL_SITE)">#NOM_SITE</a></p>]
	</div>
</div>
</BOUCLE_auteurs>

Petite explication :

  • Le code [(#CONFIG{qualif/#ID_AUTEUR-#LOGIN}|?{' ',''}) reconstruit le chemin vers la configuration de l’auteur, grâce à qualif/#ID_AUTEUR-#LOGIN, où « qualif » est le nom de l’entrée « spip_meta » de notre formulaire, et #ID_AUTEUR-#LOGIN est le nom du « casier » correspondant à l’identifiant de l’auteur ;
  • Ce premier code vérifie donc si l’auteur possède bien une configuration en mémoire, si c’est le cas, alors on affiche, dans les lignes suivantes, les qualifications enregistrées pour lui dans la base de données ;
  • Pour afficher donc les qualifications de l’auteur, on reconstruit le chemin vers chaque info mémorisée, toujours en partant de l’entrée « spip_meta », nommée « qualif » dans notre cas, puis on ajoute l’identifiant recomposé de l’auteur, qui correspond au nom de son « casier », enfin, on ajoute en dernier le nom du champ de qualification désiré, par exemple, pour la qualification en langage Html nous avons #CONFIG{qualif/#ID_AUTEUR-#LOGIN/html}, pour la qualification en techniques Spip nous aurions #CONFIG{qualif/#ID_AUTEUR-#LOGIN/spip}, et ainsi de suite pour les autres qualifications.

Ce premier code d’exemple se présente de la manière suivante :

Voyons maintenant une autre version, avec une présentation un peu différente, cette fois sous forme de tableau.

Voici le code :

<BOUCLE_auteurs(AUTEURS){id_auteur}>
<div class="mgs_bloc">
	[<div class="mgs_logo">(#LOGO_AUTEUR|right||image_reduire{60})</div>]
	<h2 class="mgs_titre">#NOM</h2>
	<div class="mgs_texte_int">
		[<div class="mgs_texte">(#BIO)</div>]
		[(#CONFIG{qualif/#ID_AUTEUR-#LOGIN}|?{' ',''})
		<div class="mgs_texte" style="margin: 5px auto; text-align: center;">
			<table class="spip" style="width: 250px;">
			<tr class="row_first"><td><strong>Technologie</strong></td><td><strong>Qualification</strong></td></tr>
			<tr class="row_odd"><td>Html</td><td>#CONFIG{qualif/#ID_AUTEUR-#LOGIN/html}</td></tr>
			<tr class="row_even"><td>Css</td><td>#CONFIG{qualif/#ID_AUTEUR-#LOGIN/css}</td></tr>
			<tr class="row_odd"><td>Js</td><td>#CONFIG{qualif/#ID_AUTEUR-#LOGIN/js}</td></tr>
			<tr class="row_even"><td>Ajax</td><td>#CONFIG{qualif/#ID_AUTEUR-#LOGIN/ajax}</td></tr>
			<tr class="row_odd"><td>Asp</td><td>#CONFIG{qualif/#ID_AUTEUR-#LOGIN/asp}</td></tr>
			<tr class="row_even"><td>Php</td><td>#CONFIG{qualif/#ID_AUTEUR-#LOGIN/php}</td></tr>
			<tr class="row_odd"><td>Spip</td><td>#CONFIG{qualif/#ID_AUTEUR-#LOGIN/spip}</td></tr>
			<tr class="row_first"><td colspan="2" style="line-height: 12px;">
				<small><em>Note : vide = acune qualification,<br />* = pratiquant, ** = confirmé, *** = expert.</em></small>
			</td></tr>
			</table>
		</div>]
		[<p class="mgs_intro">Voir en ligne : <a href="(#URL_SITE)">#NOM_SITE</a></p>]
	</div>
</div>
</BOUCLE_auteurs>

Aucun changement ici quant à la méthode de récupération des informations mémorisées par CFG, seule la présentation change ici par rapport au premier exemple, ce qui va s’afficher de la manière suivante (toujours à partir du squelette MiniGriSpip) :

CFG multi : Fonctionnement

Nous avons vu, jusqu’à là, comment mettre en place un formulaire capable d’exploiter la méthode « multi » de CFG, mais quelques points peuvent rester encore obscurs quant au mode de fonctionnement de cette méthode, nous allons donc essayer d’y voir plus clair dans ce chapitre, et nous finirons dans le chapitre suivant en parlant de quelques options avancées qui peuvent s’avérer utiles.

La table « spip_meta »

Commençons donc par étudier comment CFG mémorise les configurations dans la base de données.

Par défaut, lorque nous cliquons pour la première fois sur le bouton d’enregistrement d’un formulaire, CFG utilisera le nom du fichier de configuration, nettoyé du préfixe « cfg_ » et de l’extension « .html », pour créer une nouvelle entrée dans la table « spip_meta » portant justement le nom du fichier.

Autrement dit, si notre fichier se nomme « cfg_qualif.html », l’entrée créer par CFG dans la table « spip_meta » se nomera « qualif ».

Ceci correspond donc au fonctionnement par défaut de CFG, nous verrons dans le prochain chapitre comment faire pour forcer CFG a utiliser une autre entrée « spip_meta », et même comment faire pour mémoriser les configurations ailleurs que dans la table « spip_meta ».

La balise « #REM » lien*

Cette balise de paramétrage de CFG, [(#REM) liens*=XXX], constitue en réalité une liste de liens ciblant d’autres fichiers de configuration (l’asterisque « * » indique à CFG que la balise est une liste).

Comme il s’agit d’une liste, contrairement aux autres balises de paramétrage de CFG, nous pouvons utiliser celle-ci plusieurs fois dans le même formulaire, ainsi nous puvons créer des liens vers un ensemble cohérent de fichiers de configuration, pour un plugin par exemple.

Mais, tel que nous l’avons vu plus haut, avec cette balise de paramétrage de CFG, lorsqu’un nom du fichier ciblé correspond au nom du formulaire actif à l’écran, CFG affiche un bloc-menu particulier sur la colonne de gauche, listant l’ensemble des configurations déjà mémorisées dans la base sous l’entrée « spip_meta » portant le même nom.

Autrement dit, s’il y a concordance entre le nom du fichier de configuration actif, le nom d’une entrée « spip_meta » dans la base de données et le nom d’un lien ciblé par une balise [(#REM) liens*=XXX] présente dans le formulaire, CFG cherchera dans la base les informations correspondantes et les affichera dans un bloc-menu spécifique.

Nous verrons que si l’un de ces 3 noms venait à être différent, CFG ne sera pas en mesure de récupérer et d’afficher toutes ces informations.

La class « cfg_id »

Cet attribut, class="cfg_id", est l’élément principal de la méthode « multi » de CFG !

En effet, du moment que le formulaire de configuration comporte un objet (« input » par exemple) possédant cet attribut, CFG adaptera son mode de fonctionnement pour travailler automatiquement avec la méthode « multi ».

Bien-sûr, sans cet attribut, le fichier de configuration CFG restera oppérationnel, mais les données ne s’enregistreront pas de la même manière dans la base de données et il ne sera donc pas possible de mémoriser plusieurs configurations avec le même formulaire.

Méthode « multi » : Résumé

Pour résumer en quelques mots le fonctionnement « standard » de la méthode « multi » de CFG, disons que nous devons respecter les 3 points précédents de ce chapitre, à savoir :

  • Créer un fichier de configuration avec un nom précis [9], qui sera utilisé pour crée une entrée « spip_meta » du même nom ;
  • Insérer une balise de paramétrage de CFG de type [(#REM) liens*=XXX], où « XXX » est exactement le nom de votre fichier de configuration (sans le préfixe ni l’extension bien-sûr) ;
  • Prévoir dans votre formulaire au moins un élément comportant l’attribut class="cfg_id", pour déclencher l’utilisation de la méthode « multi ». La valeur contenue par cet élément sera utilisée pour créer les « casiers » de chaque configuration à mémoriser.

Voilà, si vous suivez ces trois préceptes, vous pourrez normalement concevoir et réaliser tout types de fichiers de configuration utilisant la méthode « multi » de CFG.

Options Avancées

Nous allons aborder dans ce chapitre quelques options avancées de CFG qui, sans être nécessaires au fonctionnement de la méthode « multi », peuvent s’avérer intéressantes à utiliser dans certains cas de figure.

Le plugin CFG a été conçu de manière à offrir plusieurs possibilités pour enregistrer les données de configuration, voyons donc quelques unes de ces options.

« spip_meta » personnalisé

Nous avons vu que, par défaut, CFG sauvegarde les configurations dans une entrée de la table « spip_meta », portant le même nom que le fichier de configuration. Cette approche est la plus simple à mettre en place et elle suffit à répondre à la plupart des situations.

Cependant, si nous souhaitons, pour une raison ou pour une autre, mémoriser nos configurations dans une entrée « spip_meta » avec un nom différent que celui de notre fichier de configuration, CFG propose un solution simple à utiliser, mais qui, hélas, n’apporte pas toutes les fonctionnalités de la méthode « multi » standard.

Voyons ça de plus près...

Partons de notre fichier de configuration « cfg_qualif.html », mais au lieu d’enregistrer les informations dans une entrée « spp_meta » nommée « qualif », du nom du fichier, nous souhaitons qu’elles s’enregistrent dans une entrée nommée par exemple « expertises ».

Éditons notre formulaire et ajoutons dans la première partie, celle contenant les paramétres de CFG, une ligne supplémentaire que voici :

<!-- Partie 1 : Parametres CFG -->
[(#REM) titre=Qualification Auteurs]
[(#REM) descriptif=<h4>Utilisation de la méthode Multi de Cfg</h4>]
[(#REM) liens*=qualif]
[(#REM) nom=expertises]

Ce nouveau paramètre, [(#REM) nom=XXX], indique à CFG de travailler avec une entrée de la table « spip_meta » portant le nom de « XXX », quelque soit le nom du fichier de configuration. Si cette entrée n’existe pas, CFG la crée automatiquement.

L’inconvénient majeur de cette option, est que CFG n’est plus en mesure d’afficher, dans le bloc-menu de la colonne de gauche, l’ensemble des configurations mémorisées, et pour cause, nous avons vu dans le chapitre précédente que CFG avait besoin que les trois noms, celui du fichier de configuration, celui de l’entrée « spip_meta » et celui du paramètre « lien », soient identiques pour pouvoir afficher de la liste des configurations sauvegardées.

Malgré l’abscence de cette liste, le fonctionnement de CFG reste le même, et nous pouvons afficher à tout moment une configuration par le bouton « Afficher » qui, grâce à la présence de l’attribut name="_cfg_affiche", utilise un mécanisme interne du plugin pour extraire les données de la base de données correspondante aux informations indiquées dans les balises de paramétrage.

Pour ce qui est de l’utilisation dans un squelette des configurations ainsi sauvegardées, la méthode reste identique, il faut seulement prendre soin d’indiquer le bon nom de l’entrée « spip_meta » à partir de laquelle nous souhaitons extraire les données, c’est-à-dire, pour notre exemple, si nous voulons afficher la qualification « Html » de l’auteur, nous aurions quelque chose comme ceci dans notre boucle « AUTEURS » :

- Html : #CONFIG{expertises/#ID_AUTEUR-#LOGIN/html}<br />

Nous avons donc remplacé, au début du chemin d’accès au données sauvegardées, le nom « qualif » par le nouveau « expertises », autrement dit, nous indiquons à CFG d’extraire les informations à partir de l’entrée « spip_meta » nommée « expertises ».

Vous trouverez, dans les archives téléchargeables en fin d’article, une version du fichier de notre formulaire, portant le nom de « cfg_qualif_meta.html », adapté avec cette option.

CFG multi et casiers

Voici donc une fonctionnalité qui va intéresser et séduire plus d’un utilisateur (votre serviteur en premier ;-).

Nous avons vu que la méthode « multi » de CFG consiste, finalement, à enregistrer chaque configuration dans des « casiers » différents, reconnaissables par un identifiant unique, à la racine de l’entrée « spip_meta » concernée.

Jusqu’à là tout bon !

Maintenant, dans notre scénario de notification des « qualifications techniques » des auteurs d’un site, imaginons que nous souhaitons affiner quelque peu leur appréciation en introduisant une séparation entre les qualifications en développement pur et leurs aptitudes à rédiger de la documentation...

En effet, nous savons tous qu’un génie en développement peut être un médiocre pédagogue et, inversement, un développeur aux compétences plutôt modèstes peut s’avérer un excellent vulgarisateur.

Pour simplifier les choses, nous pourrions juste ajouter une case à cocher du genre : « Bonnes aptitudes pour la documentation », ou « Très bon vulgarisateur », « Excellent pédagogue », etc.

Mais, comme nous sommes pinailleurs, nous souhaitons faire une appréciation par technologie Web listée, autrement dit, nous utiliseront exactement les mêmes informations et donc le même formulaire pour les deux types de notations [10].

Comment faire alors pour séparer ces appréciations ?

La solution vient de l’utilisation des « casiers » imbriqués dans ceux créés au premier niveau par la méthode « multi ».

Voici comment nous allons procéder :

Commençons donc par éditer notre fichier de configuration « cfg_qualif.html ». Puis, dans la 3e partie du code, celle concernant la configuration, nous allons ajouter un simple menu déroulant, avec comme options les termes « Documentation » et « Développement », leurs valeurs respectives seront des simples abréviations comme « doc » et « dev », voici le code :

<select name="casier" class="cfg_id" id="casier" title="Choisissez un domaine">
	<option value="dev" [(#ENV{casier}|=={'dev'}|?{selected="selected"})]>Développement</option>
	<option value="doc" [(#ENV{casier}|=={'doc'}|?{selected="selected"})]>Documentation</option>
</select>
  • Nous pouvons remarquer la présence de l’attribut class="cfg_id" qui, comme nous l’avons déjà vu, permet à CFG de déclencher la méthode « multi » tout en créant des « casiers » avec la valeur de lobjet où il se trouve. C’est justement cet attribut qui, combiné avec le même attribut d’un autre objet, indiquera à CFG d’imbriquer ces différents « casiers », selon leur ordre d’apparition dans le code.

Le but est finalement d’obtenir une hiérarchie dans la sauvegarde des données de ce type :

  • qualif
    • auteur 1
      • doc
        • info 1
        • info 2
      • dev
        • info 1
        • info 2
    • auteur 2
      • doc
        • info 1
        • info 2
      • dev
        • info 1
        • info 2
    • etc.

Voici à quoi ressemble la partie « Configuration » de notre formulaire avec cette option :

Seul inconvénient de cette technique est que CFG ne sais pas afficher, dans le bloc-menu de la colonne de gauche, les différents « casiers » imbriqués, il ne peut afficher que le premier niveau, c’est à dire la liste des auteurs pour notre projet.

Malgré tout, toujours grâce au bouton « Afficher », nous pouvons récupérer et afficher les données enregistrées de la manière suivante :

  • Sélectionnons tout d’abord un élément de la liste générée par CFG qui se trouve dans le bloc-menu de la colonne de gauche ;
  • Choisissons ensuite dans le menu déroulant le domaine « Développement » ou « Documentation » qu’on désire afficher ;
  • Enfin, il suffit de cliquer sur le bouton « Afficher » pour visualiser les données sauvegardées.

Pour l’utilisation des données dans nos squelettes, il suffit d’indiquer à CFG le chemin d’acces, toujours en commançant par le nom de l’entrée « spip_meta », puis en ajoutant les noms des différents casiers imbriqués, enfin, en indiquant la valeur qu’on souahite afficher, ce qui nous donnne, si par exemple nous souhaitons afficher les aptitudes en documentation Html d’un auteur :

- Html : #CONFIG{qualif/#ID_AUTEUR-#LOGIN/doc/html}<br />

Vous trouverez, dans les archives téléchargeables en fin d’article, une version du fichier de notre formulaire, portant le nom de « cfg_qualif_casier.html », adapté avec cette option.

Les « storage »

Comme nous le disions en introduction à ce chapitre, CFG offre plusieurs possibilités et options pour sauvegarder les configurations, nous venons d’en voir deux, mais elles ont en commun d’utiliser la table « spip_meta » pour enregistrer les informations.

Or, dans un souci manifeste de faire de CFG un outil souple et polyvalent, susceptible de convenir à des nombreuses situations, notre ami Toggg a eu la bonne idée d’implémenter d’autres possibilités de sauvegarde des configurations.

En effet, nous pouvons demander à CFG d’utiliser d’autres « espaces » pour enregistrer les données, ainsi il existe au total 4 possibilités, au choix selon les besoins, regroupés sous l’appélation « storage » :

  • metapack
    Cette option est celle utilisée par défaut par CFG, c’est à dire la sauvegarde des données dans la table « spip_meta », nous n’avons pas besoin de la déclarer explicitement ;
  • extrapack
    Cette option nécessite une déclaration explicite, et elle indique à CFG d’enregistrer les données dans le champ « extra » de la table « spip_auteurs » par défaut, ou dans n’importe quelle autre table disposant de ce type de champ, mais on doit l’indiquer explicitement ;
  • table
    Il est donc aussi possible de demander à CFG d’enregistrer les données dans une table précise et, normalement, dans un champ précis de la table choisie, mais, malheureusement, malgré mes nombreux essais, je ne suis pas parvenu à utiliser cette option avec succès (« erreur d’enregistrement » retourné à chaque tentative), elle ne sera donc pas d’avantage traitée dans cet article. En revanche, si un lecteur du présent didacticiel peut apporter quelques pistes ou solutions pour utiliser correctement cette option, il est évidemment le bienvenue.
  • php
    Dernière possibilité, l’enregistrement des informations dans un fichier de type Php, sous forme d’un tableau « array() » de données. Il suffit ensuite d’inclure ce fichier dans un autre code Php pour pouvoir utiliser les données ainsi sauvegardées. Nous n’approfondirons pas d’avantage cette option, qui n’a d’utilité, a priori, que si la base de données est inaccessible.

Les champs « extra »

Pour finir avec ce chapitre des options avancées de CFG, disons quelques mots sur l’utilisation du champ « extra » pour sauvegarder les configurations.

Revenons un instant sur notre scénario de départ.

Nous voulons mémoriser, pour chaque auteur du site, des appréciations quant à leurs compétences techniques en développement Web. D’accord, mais, au lieu d’enregistrer ces informations dans la table « spip_meta », pourquoi ne pas le faire directement dans la table « spip_auteurs », ce serait somme toutes plus logique et cohérent.

Seulement, en regardant de près la table « spip_auteurs », nous n’avons pas de champ spécialement adapté à recevoir les infos qu’on désire sauvegarder... en revanche, cette table dispose d’un champ particulier pouvant aisément être utilisé pour nos données, il s’agit du champ « extra » [11].

Pour indiquer à CFG d’utiliser le champ « extra » de la table « spip_auteurs », il suffit d’ajouter une balise « #REM » de parmétrage spécifique à notre première partie du code, c’est à dire :

<!-- Partie 1 : Parametres CFG -->
[(#REM) titre=Qualification Auteurs]
[(#REM) descriptif=<h4>Utilisation de la méthode Multi de Cfg</h4>]
[(#REM) liens*=qualif]
[(#REM) storage=extrapack]
  • Cette balise de paramétrage [(#REM) storage=extrapack], indique donc explicitement à CFG d’enregistrer les données de chaque configuration dans le champ « extra » de l’auteur concerné.

Mais comment faire pour cibler le bon auteur ?

La solution réside dans l’utilisation (impérative ?) du numéro d’identification unique de l’auteur généré automatiquement par Spip, c’est cet identifiant qui permettra à CFG de savoir dans quel champ « extra » enregistrer chaque configuration.

Nous devons donc faire très attention, avec cette méthode de sauvegarde, de fournir à CFG le bon identifiant, et ceci est d’autant plus vrai si nous désirons employer le champ « extra » d’une autre table que « spip_auteurs », qui est la table par défaut utilisée par CFG avec la méthode « extrapack ».

En effet, nous pouvons facilement indiquer à CFG d’utiliser le champ « extra » de n’importe quelle autre table de la base de données qui en possède, par exemple, si nous décidons de sauvegarder nos données dans champ « extra » de la table « spip_articles », nous devons ajouter une nouvelle balise de paramétrage de CFG spécifiant le nom de la table à utiliser, comme ceci :

<!-- Partie 1 : Parametres CFG -->
[(#REM) titre=Qualification Auteurs]
[(#REM) descriptif=<h4>Utilisation de la méthode Multi de Cfg</h4>]
[(#REM) liens*=qualif]
[(#REM) storage=extrapack]
[(#REM) table=spip_articles]
  • C’est avec cette balise de paramétrage [(#REM) table=spip_articles] que CFG saura de quelle table utiliser le champ « extra ». Mais, dans ce cas, nous devons faire attention à fournir le « id_article » comme identifiant pour que CFG sache dans quelle entrée de cette table enregistrer les données.

Vous trouverez, dans les archives téléchargeables en fin d’article, une version du fichier de notre formulaire, portant le nom de « cfg_qualif_extra.html », adapté avec cette option.

Conclusion

Le plugin CFG est vraiment surprenant, autant par les nombreuses options et possibilitées qu’il offre, que par sa simplicité d’utilisation et de mis en oeuvre.

En revanche, il peut être aussi parfois un peu déroutant car, en fouillant, on peut découvrir des nouvelles fonctionnalités ou options, mais comme elles ne sont malheureusement pas toutes documentées, on peut investir pas mal de temps pour percer leurs secrets, et quelquefois même ne pas y parvenir (le « storage » de type « table » en est un exemple en ce qui me concerne).

Mais, ne nous attardons pas sur les quelques points qui restent encore à éclaircir, et réjouissons-nous plutôt de disposer d’un outil si bien conçu et si pratique à l’usage. Je suis persuadé que CFG nous réserve encore quelques bonnes surprises, en tout cas, ce qui est d’ors et déjà certain, c’est qu’il sera de plus en plus populaire et, qui sait, il se pourraît même qu’il soit un jour intégré par défaut dans le moteur de Spip, ce qui ne m’étonnerai vraiment pas.

Voilà, nous arrivons à la fin (enfin dirons certains ;-) de ce long, très looong didacticiel, qui tente d’apporter, parfois avec quelques redondances, le plus grand nombre d’informations et d’explications pour vous aider à comprendre et à utiliser le plugin CFG au mieux de ses possibilités, notamment en ce qui concerne sa méthode « multi ».

J’espère de tout coeur que, un jour ou l’autre, cet article vous sera un peu utile...

Téléchargement

 Formulaire Qualif 

Remerciements

Bien évidemment, mes premiers remerciements sont pour Toggg, pour son implication dans l’univers Spip et aussi pour nous avoir « pondu » des outils aussi incontournables comme CFG.

Je tiens à remercier également Matthieu Marcillaud, pour son aide et pour avoir pris la suite du développement de CFG.

Enfin, je remercie aussi de manière collective, mais je pense individuellement à chacun d’eux, tous les Spipeurs qui m’ont aidé personnellement ou qui ont donné un peu de leur temps pour le bienfait de toute la communauté.

Notes

[1Développeur de talent et de tempérament, Toggg a activement contribué à des nombreux projets et est à l’origine de bien d’autres, dont le plugin CFG. Aujourd’hui le développement de CFG continue sur SPIP-Zone, notamment sous l’impulsion de Matthieu Marcillaud, alias « marcimat ».

[2Dans ce cas, il ne s’agit pas d’informations de « configuration » à proprement parler, mais plutôt des données supplémentaires à sauvegarder et à utiliser, pour lesquelles la base de données de Spip ne dispose pas de table dédiée. Pour ne pas créer de confusions, nous allons ici continuer à parler de « configuration » pour désigner toutes les données manipulées avec CFG, quelque soit leur rôle.

[3Cette méthode, « multi », doit certainement son nom à la nécessité de différencier les configurations simples des configurations multiples ou « multi-configurations ».

[4En plus des balises « #REM », CFG autorise l’utilisation des commentaires Html pour certains paramètres, comme le « titre » ou le « descriptif », par ex. <!-- titre=Mon titre -->. Je reprends l’explication de Toggg, « Ici, le descriptif sera complètement interprété, comme un squelette ... y compris boucles et toute la machine de guerre SPIP ».

[5Le « casier » n’est autre chose qu’un tableau de données de type « array() » en langage Php, qui servira à réunir toutes les informations concernant une configuration. Voir Cfg : références pour plus amples informations sur les « casiers ».

[6Le dernier « p » de l’acronyme « SPIP » veut-il dire : participatif ?... partagé ?... pour tous ?... en tout cas, voici la petite histoire de Spip.

[7Nous pouvons donc conclure que c’est la concordance entre le nom du fichier de configuration et le nom « XXX » du fichier cible inscrit dans la balise de paramètrage [(#REM) liens*=XXX], qui permet à CFG d’afficher ce bloc-menu. Ceci n’est pas une particularité spécifique à la méthode « multi », nous pouvons aussi bénéficier de la présence de ce bloc-menu avec la technique des « casiers ».

[8L’identifiant « 3-pierre » se compose de : « 3 » = numéro d’identification unique de l’auteur attribué par Spip, « pierre » = le login de l’auteur. Ces données sont issues des balises "#ID_AUTEUR-#LOGIN" de la boucle « AUTEURS » qui construit le menu déroulant.

[9Le nom du fichier de configuration, c’est à dire la partie qui vient après le préfixe « cfg_ » (obligatoire) et l’extension « .html », ne doit contenir ni d’espace ni de caractère accuenté ou spécial et être, de préférence, écrit tout en minuscules. Si vous respectez ces consignes, vous ne devrez pas avoir de soucis pour que CFG reconnaîsse et utilise votre fichier de configuration.

[10Bien-sûr, dans ce cas de figure, reprendre le même formulaire pour des appréciations de nature bien différente, ce n’est certainement pas la meilleure solution, mais elle convient parfaitement pour illustrer la technique des « casiers » avec la méthode « multi ».

[11Toutes les tables de la base de données de Spip ne possèdent pas de champ « extra », seules les plus importantes en disposent, c’est à dire : « spip_articles », « spip_auteurs », « spip_breves », « spip_mots », « spip_rubriques » et « spip_syndic ».

Discussion

4 discussions

  • 2

    Un article passionnant qui m’a permis de comprendre ce qu’est le plugin cfg dont tout le monde parle, un article bien écrit et didactique. Si j’avais des droits administrateurs, j’aurais corrigé les quelques coquilles que j’y ai vu.

    En tout cas, je sais déjà a quoi il va me servir maintenant le plugin cfg.

    • Bonjour Cent20 et merci pour ton appréciation... :-)

      J’ai vu aussi quelques coquilles et certaines phrases à améliorer/clarifier, je tâcherai de le faire dans la semaine...

      Sinon, heureux que ce « petit » article ait pu t’éclairer un peu sur ce qu’on peut faire avec CFG... et comme il ne couvre pas toutes les possibilités offertes par le plugin, je suis certain que tu découvriras d’autres options fort utiles...

      Merci encore... à+ :-)

    • Bonjour et merci beaucoup pour ce tuto qui est vraiment clair et présente des possibilités de développement de plugins surprenantes via CFG ^^

      Je pense que je vais faire des tests sur les possibilités d’enregistrement de config grâce à la méthode tablepack qui me semble être très adaptée pour éviter la surcharge de spip_meta et mieux dispatcher les infos.

      Encore bravo et merci !!!

    Répondre à ce message

  • Bonjour FredoMkb

    Je laisse un message ici pour signaler un changement dans CFG concernant les champs multi ; changements introduits dans la version 1.3 du plugin de ce jour.

    Ce qui change, c’est le paramètre <!-- liens*= --> qui ne fait maintenant qu’afficher un lien vers le fond CFG dont on passe le nom. Il n’affichera plus le formulaire des champs ’multi’.

    Pour afficher le formulaire ’multi’ comme avant, il faut mettre à la place de liens* : <!-- liens_multi*= -->

    Par ailleurs, je signale que depuis la version 1.2 de CFG, le passage de paramètre [(#REM) param=valeur ] est déprécié (mais fonctionne encore) au profit de l’unique écriture <!-- param=valeur -->

    MM.

    Répondre à ce message

  • Bonjour FredoMkb

    Je laisse un message ici pour signaler un changement dans CFG concernant les champs multi ; changements introduits dans la version 1.3 du plugin de ce jour.

    Ce qui change, c’est le paramètre qui ne fait maintenant qu’afficher un lien vers le fond CFG dont on passe le nom. Il n’affichera plus le formulaire des champs ’multi’.

    Pour afficher le formulaire ’multi’ comme avant, il faut mettre à la place de liens* :

    Par ailleurs, je signale que depuis la version 1.2 de CFG, le passage de paramètre [(#REM) param=valeur ] est déprécié (mais fonctionne encore) au profit de l’unique écriture

    MM.

    Répondre à ce message

  • 1

    Salut,

    Je suis en train de jouer avec tes fichiers, que j’ai mis dans le dossier fonts d’un plugin actif, et j’ai l’erreur suivante :

    Fatal error : Call to undefined function spip_fetch_array() in D :\www\cent25\plugins\cfg\cfg_options.php on line 87

    lorsque je clique sur afficher dans Configuration sur toutes les pages.

    Je suis en SPIP SVN « SPIP 1.9.3 dev SVN [10648] » , je pense qu’il y a un truc qui bloque avec spip_fetch_array().

    Cordialement,

    • Hum apparemment c’est une fonction du plugin config qui a changé de nom :

      spip_fetch_array() déprécié

      Donc le bug vient de la version de cfg que j’utilise, je vais de ce pas récupérer la version SVN.

      J’ai corrigé le bug en modifiant cfg.

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom