#CONFIGURER_METAS

Documentation

Cette 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. Elle vérifie son existence et fournit un trio de fonctions CVT par défaut pour son utilisation.

- Si cet argument est absent, il est pris conventionnellement égal à configurer_préfixe_du_plugin.

Pour chacune des 3 fonctions, s’il existe une fonction homonyme au nom du squelette, c’est elle qui prend la main.

Exemple : pour ’charger’ et le plugin ’Association’, la fonction < code>association_charger</code > association_charger qui 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.

Le chemin d’accès au squelette détermine la table des métas associée.
-  s’il commence par _DIR_PLUGINS ou _DIR_EXTENSIONS (autrement dit si le formulaire a été trouvé dans un plugin), la table des métas associée est celle du plugin (qui est par défaut le préfixe du plugin, suivi de _metas).
-  sinon c’est la table des métas standard.

Le traitement des saisies consiste à écrire dans la cette table des metas associée les valeurs (chaîne vide si absentes abstentes ) que $_POST indique pour toutes tous les saisies trouvées noms trouvés dans le formulaire. , à l’aide d’une RegExp  ? Pour les chercher , une RegExp est utilisée pour reprérer les < code>name</code > (pas totalement fiable). ) repérant les attributs name dans le formulaire . Ce traitement est assuré par la fonction formulaires_configurer_plugin_traiter_dist.

Pour fonctionner correctement, les formulaires référencés (implicitement ou non) par cette balise doivent utiliser #ACTION_FORMULAIREavec comme deuxième argument le nom du plugin . Cela assure que le trio de fonctions ci-dessus décrit soit effectivement utilisé.Souvent, on peut utiliser les valeurs par défaut et donc utiliser #ACTION_FORMULAIRE sans aucun argument.

Sans argument, les valeurs par défaut des 2 arguments de #ACTION_FORMULAIRE sont utilisées : 1) #ENV{action} et 2) / le nom du plugin / le nom du formulaire / ( ?? préciser ).

Question : pendant un moment dans Association2, le 2^e argument valait devait valoir ’configurer_plugin’. ’, et non le nom du plugin comme recommandé ci dessus . ça correspondait à quoi ? (cf http://zone.spip.org/trac/spip-zone...) Cela a donc changé ? Je n’ai pas vu où. Ou bien cette partie est fausse ?)

Le contexte de ce squelette contient les valeurs de la table des métas associée, qui en mémorise les valeurs précédemment saisies, ou les valeurs par défaut.

Utiliser et tester #CONFIGURER_METAS

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

Références SVN

Cette balise s’est antérieurement appelée #REMPLIR, et encore avant : #FORMULAIRE_CONFIGURER_PLUGIN. Sans faire de l’achéologie, voici les étapes ce création :

-  création de #FORMULAIRE_CONFIGURER_PLUGIN

-  complément

On y trouve d’utiles précisions toutes encores valables ? :

<blockquote class="spip">

Le contexte de ce squelette est égal à la table des métas associée à ce plugin le nom de cette table étant calculé par la fonction formulaires_configurer_plugin_charger_dist.

On y trouve une précision  :
< quote >
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.

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.

</blockquote>

-  retour, simplification & corrections

-  renommage en #REMPLIR, retrait de la branche 2.1

puis :

-  renommage en #CONFIGURER_METAS...

Alternatives et limitations Limitations actuelles

- CFG : #CONFIGURER_METAS a pour vocation à remplacer #CFG dans un certain nombre de cas, mais CFG semble plus riche fonctionnellement. 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 il n’y a 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 magique depuis les formulaires gérés par le plugin CFG