Version 3 — Août 2010 — Déesse A.
Cette balise gère dans une table SQL les saisies d’un squelette de formulaire donné en argument. La table SQL à utiliser est déduite de l’endroit où le squelette est trouvé. Elle est essentiellement utilisée pour configurer les Plugins, notamment en l’utilisant dans le squelette
NOM-PLUGIN/prive/exec/configurer_PREFIXE-PLUGIN.html (où NOM-PLUGIN et PREFIXE-PLUGIN figurent le nom et le préfixe du Plugin à configurer). Un squelette ainsi nommé est automatiquement associé à l’icone de configuration (clé plate et tournevis) dans la page des Plugins installés. Par exemple,
voici le contenu de
Association_2.0/prive/exec/configurer_association.html :
[(#AUTORISER{configurer})
<!--#navigation-->
<div class='cadre cadre-info'><:asso:info_doc:></div>
<!--/#navigation-->
<h1><:asso:titre_page_config:></h1>
#CONFIGURER_METAS{configurer_association}
]
L’argument de #CONFIGURER_METAS, dans l’exemple ci-dessus le squelette configurer_association,
se trouve quant à lui dans le répertoire formulaires
du Plugin.
Le formulaire contenu dans ce squelette doit se conformer au mécanisme CVT en utilisant #ACTION_FORMULAIRE pour provoquer l’appel du trio de fonctions caractéristique de ce mécanisme.
Il n’est pas nécessaire de donner des arguments à # ACTION_FORMULAIRE Sans argument , les valeurs par défaut étant celles souhaitées des 2 arguments de # ACTION_FORMULAIRE sont utilisées : 1 )
#ENV{action}</code > et 2 ) {/ le nom du plugin / le nom du formulaire / (à savoir < code>#ENV{action}</code >). ?? préciser )}.
Le contexte de ce squelette contient les valeurs de la table SQL des métas associée, qui en mémorise les valeurs précédemment saisies, ou les valeurs par défaut .
Le chemin d'accès au squelette détermine la table des métas associée.
La table SQL associée est déterminée par le chemin d'accès au squelette selon le principe suivant :
- s'il commence par _DIR_PLUGINS ou _DIR_EXTENSIONS (autrement dit si le formulaire a été trouvé dans un Plugin plugin ), c'est la table des métas associée est celle du Plugin plugin (qui est par défaut son le préfixedu plugin , suivi de _metas).
- sinon c'est la table des métas standard de SPIP .
{{Cette balise s'applique pour un plugin ou dans un simple dossier squelette. Elle permet de présenter un formulaire de saisies dont les valeurs sont enregistrées dans une table de métas. C'est une manière pour le webmaster de paramétrer le fonctionnement du plugin ou du squelette.}}
Cette balise prend un unique argument : un squelette de formulaire. La balise Elle vérifie l'existence du squelette de formulaire donné en argument , son existence et fournit un trio de fonctions CVT par défaut pour son utilisation. Elle cherche également automatiquement les noms des saisies à mémoriser, à l'aide d'une RegExp qui repère les attributs <code>name
. Il est à noter que cette méthode ne repère donc pas les noms de saisie produits par des balises SPIP (en particulier #SAISIE
).
- Si cet argument est absent, il est pris conventionnellement égal à configurer_préfixe_du_plugin.
Pour chacune des 3 fonctions CVT , s’il existe une fonction homonyme au nom du squelette, c’est elle qui prend la main. Par exemple : pour charger
et le plugin ’Association’, la fonction association_charger
sera recherchée, et utilisée si elle existe.
La fonction _charger
consulte la table SQL associée pour y lire les valeurs des saisies fournies lors d’une éventuelle précédente utilisation, et fabriquer le contexte d’exécution du squelette.
La fonction _verifier
ne fournit aucun service, aucune opération de vérification générale ne pouvant être devinée.
Exemple : pour ’charger’ et le plugin ’Association’, la fonction association_charger
sera recherchée dans le répertoire formulaire, et utilisée si elle existe.
- Sinon, la table des métas associée à ce formulaire est utilisée pour y lire les valeurs (fonction _charger) et les y écrire (fonction _traiter). Rien n’est fait pour la fonction _verifier.
La fonction < code>traiter</code > écrit Le traitement consiste à écrire dans la table SQL des metas associée les valeurs (chaîne vide si absentes) que $_POST indique pour tous toutes les noms de saisies trouvées dans le formulaire.Pour les chercher, une RegExp est utilisée pour reprérer les name
(pas totalement fiable).
Pour fonctionner correctement, les formulaires référencés (implicitement ou non) par cette balise doivent utiliser #ACTION_FORMULAIRE. Cela assure que le trio de fonctions ci-dessus décrit soit effectivement utilisé.
Question : pendant un moment dans Association2, le 2e argument valait ’configurer_plugin’. ça correspondait à quoi ? (cf http://zone.spip.org/trac/spip-zone...)
Cette balise n’est présente que dans la branche SPIP 2.2.
Pour l’expérimenter dans un SPIP 2.1.1, il suffit de copier les deux fichiers ecrire/balise/configurer_metas.php
et prive/formulaires/configurer_metas.php
.
Exemple :
- plugin Association
- Migration du plugin Association vers CONFIGURER_METAS
Cette balise s’est antérieurement appelée #REMPLIR, et encore avant : #FORMULAIRE_CONFIGURER_PLUGIN.
Les Sans faire de l’achéologie , voici les étapes ce création sont les suivantes ( attention , certaines informations dans ces pages ne sont plus d’actualité ) : :
- création de #FORMULAIRE_CONFIGURER_PLUGIN
On y trouve une précision :
<blockquote class="spip">Pour la vérification, la fonction formulaires_configurer_plugin_traiter_dist délègue le travail à la fonction formulaires_nom_du_squelette_verifier si elle existe, et sinon ne fait rien.
On y trouve une précision :
< quote >
Ces trois fonctions sont donc communes à tous les formulaires de configuration de tous les plugins voulant les utiliser, ainsi que leurs fonctions auxilaires (nomenclatures des saisies notamment). Elles peuvent évidemment être surchargées.
- retour, simplification & corrections
- renommage en #REMPLIR, retrait de la branche 2.1
puis :
- renommage en #CONFIGURER_METAS...
- CFG : #CONFIGURER_METAS a pour vocation à remplacer #CFG dans la plupart des un certain nombre de cas, en étant beaucoup moins volumineux en code et en consommation mémoire mais CFG semble plus riche fonctionnellement . Les autres cas sont formés par les noms de saisies difficilement détectables à la compilation, ainsi que les saisies structurées. Si on veut abandonner CFG pour ces cas aussi, une reconception du code l’utilisation sera nécessaire.A préciser.
- BONUX : Le bonux BONUX implémente également un mécanisme de configuration, utilisé notamment par le plugin COMMENTS. A présenter également.
CONFIGURER_METAS ne fait pas consensus.
On lui reproche notamment les limitations suivantes :
- un form de configuration du core utilisant CONFIGURER_METAS ne peut pas etre surchargé par un plugin
- un form de configuration d’un plugin utilisant CONFIGURER_METAS ne peut pas être surchargé dans dossier_squelettes
- CONFIGURER_METAS ne propose pas de méthode pour lire les metas dans les skels
- pour les nombreux formulaires gérés par CFG, il n’y a pas d’outils de migration vers CONFIGURER_METAS