Carnet Wiki

#CONFIGURER_METAS

SPIP-Contrib :: Carnet Wiki :: Recherche :

#CONFIGURER_METAS

voir la Documentation définitive sur http://www.spip.net/fr_article5414.html
et le filtre sinon_interdire_acces introduit par Balises Bonux.

Documentation

Cette balise gère dans une table SQL les saisies d’un squelette de formulaire donné en argument. La table SQL à utiliser est soit la table standard des meta du noyau de SPIP, soit une table construite pareillement et dont le nom est fourni par l’entrée meta de fichier XML décrivant le Plugin fournissant ce squelette de formulaire.
Cette balise 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 :

  1. [(#AUTORISER{configurer})
  2. <!--#navigation-->
  3. <div class='cadre cadre-info'><:asso:info_doc:></div>
  4. <!--/#navigation-->
  5. <h1><:asso:titre_page_config:></h1>
  6. #CONFIGURER_METAS{configurer_association}
  7. ]

Télécharger

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 : les valeurs par défaut étant celles souhaitées (à savoir #ENV{action}).

Le contexte de ce squelette contient les valeurs de la table SQL associée, qui en mémorise les valeurs précédemment saisies.

La table SQL associée est déterminée par le chemin d’accès au squelette de formulaire selon le principe suivant :
-  s’il commence par _DIR_PLUGINS ou _DIR_EXTENSIONS (autrement dit si le formulaire a été trouvé dans un Plugin), c’est la table des métas du Plugin (qui est par défaut son préfixe, suivi de _metas).
-  sinon c’est la table des métas standard de SPIP.

La balise vérifie l’existence du squelette de formulaire donné en argument, 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 name.
-> Il est à noter que cette méthode n’évalue pas (par recuperer_fond) les squelettes et ne repère donc pas les noms de saisie produits par des balises SPIP (en particulier #SAISIE) ou par des BOUCLES ou INCLURE.

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.

La fonction traiter écrit dans la table SQL associée les valeurs (chaîne vide si absentes) que $_POST indique pour tous les noms de saisies trouvées dans le formulaire.

Lorsque les valeurs sont stockées dans la table spip_metas standard, on peut les récupérer dans un squelette avec la balise #CONFIG. Sinon, il faut
utiliser une nouvelle balise : #META..

Utiliser et tester #CONFIGURER_METAS et #META

Ces balises ne sont pour l’instant pas présentes dans les branches de développement de SPIP, mais figurent dans plusieurs plugins (cette duplication des fichiers n’empêche pas de les utiliser simultanément, la fonction include_spip s’arrêtant au premier trouvé). On les trouve par exemple dans le plugin SPIPAL, dont on recopiera les 3 fichiers :

balise/meta.php,
balise/configurer_metas.php et formulaires/configurer_metas.php.

Exemple :

-  plugin Association
-  Migration du plugin Association vers CONFIGURER_METAS

Bienfaits de CONFIGURER_METAS

-  code efficace à l’exécution (une regexp mais pas de récupérer_fond)
-  code concis
-  permet de configurer sans écrire de php

Alternatives et limitations actuelles

#CONFIGURER_METAS ne fait pas consensus. On lui reproche notamment les limitations suivantes (merci de corriger au besoin) :
-  #CONFIGURER_METAS ne repère pas les noms de saisie produits par la balise #SAISIE et les autres balises SPIP, ou produites par des BOUCLES ou INCLURE
-  un formulaire de configuration du core utilisant #CONFIGURER_METAS ne peut pas être surchargé par un plugin
-  un formulaire de configuration d’un plugin utilisant #CONFIGURER_METAS ne peut pas être surchargé dans dossier_squelettes
-  pour les nombreux formulaires gérés par CFG, il n’y a pas d’outils de migration vers #CONFIGURER_METAS
-  selon le dossier où le squelette de formulaire appelé est placé, la balise ne stockera pas la meta dans la même table (ce qui peut représenter une faiblesse)

Il y a plusieurs alternatives :

-  CFG : #CONFIGURER_METAS a pour vocation à remplacer #CFG dans la plupart des cas, en étant beaucoup moins volumineux en code et en consommation mémoire. 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.

-  BONUX : Le plugin BONUX implémente également un mécanisme de configuration : une balise #FORMULAIRE_CONFIGURER_xxx qppelée pour tout formulaire CVT si aucune fonction charger() ni traiter() n’est définie. Utilisé notamment par le plugin COMMENTS

Le mécanisme de configuration de Bonux est désormais intégré dans les versions de dev du core.

Quelques références SVN pour #configurer_metas

La balise CONFIGURER_METAS s’est antérieurement appelée #REMPLIR, et encore avant : #FORMULAIRE_CONFIGURER_PLUGIN.
Chronologie des étapes de création de la balise (attention, certaines informations dans ces pages ne sont plus d’actualité) :

-  création de #FORMULAIRE_CONFIGURER_PLUGIN

-  complément

On y trouve une précision :

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...