Unique fichier de configuration
CFG a été motivé par le besoin récurrent de fabriquer des configurations de plugins ou squelettes.
Son leitmotiv est donc la simplicité. C’est pourquoi une configuration "quelque_chose" (un plugin, un squelette ou ce que l’on veut) est basée sur l’unique fichier fonds/cfg_quelque_chose.html [1].
Ce "fond" contient un formulaire et des propriétés/options qui sont transmises à CFG.
La modification des données (par un administrateur du site) se fait par simple appel de l’action CFG comme
ecrire/?exec=cfg&cfg=quelque_chose où quelque_chose correspond au nom du fichier fonds/cfg_quelque_chose.html.
Le formulaire
Il s’agit d’un formulaire HTML standard, interprété comme un squelette. Les données gérées sont reconnues d’après l’attribut "name" des balises de formulaire comme
-
<input type="text" name="truc"...>, -
<select name="truc"...>, -
<textarea name="truc" ...>, - etc.
Notes sur le nomage des attributs "name"
- Les noms commençant par _cfg_ sont réservés au fonctionnement interne.
- Les noms commençant par id_ peuvent poser problème. [2]
Transmettre une action sécurisée
L’action du formulaire étant sécurisée, il faut lui adjoindre les données de contrôle, tout simplement en faisant suivre <form ...> par des "hidden" le plus simple étant :
<form method="post" action="#SELF">[(#ENV{_cfg_}|form_hidden)]
Boutons d’envoi et de suppression
Enfin, les submit de validation ou de suppression doivent être nommés respectivement _cfg_ok ou _cfg_delete (noms réservés)
Formulaire minimal
Un formulaire minimal serait donc :
Comme on peut le voir, les valeurs des données sont récupérables par #ENV{truc}
Important : La méthode d’analyse des formulaires de CFG implique de respecter l’ordre suivant (type puis name, puis les éventuelles class css, puis le reste) dans les balises utilisées (textearea, select, input...).
<input type=... name=... class=... .../>
<textearea/select name=... class=... .../>
Les propriétés de l’objet cfg
Il est possible en plaçant des remarques au format html commençant par propriete= de spécifier des propriétés intrinsèques de l’objet CFG qui manipulera le formulaire.
Par exemple, on peut ainsi définir le titre du formulaire (notez l’espace après <!-- et le = collé au nom du paramètre) :
<!-- titre=Le titre du formulaire -->
Il est possible alors de jouer avec les balises SPIP et les fichiers de langue :
<!-- descriptif=<multi>[fr]Descriptif français [en]In english</multi>-->
<!-- descriptif=<:prefixe_plugin:description_plugin:>-->
Ici, le descriptif sera complètement interprété, comme un squelette ... y compris boucles et toute la machine de guerre SPIP.
| Propriété | Description |
| titre | Un des 2 titres, fera le gros titre si boite est aussi présent |
| boite | Le titre de la boite formulaire, défaut titre si présent, ’Configuration machin" sinon |
| descriptif | Le descriptif affiché en haut de colonne gauche |
| nom | Le nom du meta où sera stockée la configuration, par défaut c’est le nom du formulaire, xxx dans fonds/cfg_xxx |
Il existe d’autres propriétés avancées que vous pouvez trouver dans l’article API CFG : Paramètres des formulaires
Utilisation des données
Les données stockées sont sérialisées sous le nom "quelque_chose" dans la table spip_meta.
On les récupère dans les squelettes avec la balise #CONFIG qui est étendue par cfg pour extraire les subdivisions avec le séparateur /
Par exemple #CONFIG{quelque_chose/mon_area} donnera la valeur du champs mon_area produite par le formulaire fonds/cfg_quelque_chose.html
Depuis le php, on peut utiliser similairement lire_config('quelque_chose/mon_area')
#CONFIG{} ou lire_config() admettent comme deuxième paramètre la valeur à retourner par défaut. Par exemple #CONFIG{quelque_chose/mon_area,defaut area} donnera defaut area si quelque_chose ou mon_area sont vides.
RSS 2.0