N'hésitez pas à corriger ou compléter cette page
qui contient
- une documentation - à confirmer et préciser
- un exemple - à compléter par d'autres ?
- les références svn pour approfondir et éclairer les points obscurs
- alternatives et limitations
Cela facilitera les tests et la connaissance de cette balise,
son usage et éventuellement son développement ou son retrait.
Cela vise à faire avancer le débat en tout cas.
Merci Jean-Luc. J'ai beaucoup remanié cette page pour que les infos que tu a collectées soient mieux reliées entre elles. N'hésite pas à y re-corriger encore ou poser des questions si besoin.
Pour ta Question :
pendant un moment dans Association2, le 2eme argument valait 'configurer_plugin'. ça correspondait à quoi ? (cf [->Connexion · GitLab])}
c'était une version où le compilateur ne savait pas comprendre tout seul qu'il fallait utiliser "configurer_plugin", à présent il sait le faire.
Merci Jean-Luc. J'ai beaucoup remanié cette page pour que les infos que tu a collectées soient mieux reliées entre elles. N'hésite pas à y re-corriger encore ou poser des questions si besoin.
OK on y voit plus clair.
Vis a vis des débutants je me souviens aussi qu'un intérêt de CONFIGURER_METAS est de permettre la création d'un formulaire de config SANS faire de PHP.
Pourtant, le seul moyen de récupérer les valeurs est de coder en PHP (dans association, ça se fait soit via un accés à $_GLOBALS soit via lire_config). Ne faudrait il pas pouvoir accéder à ces valeurs via une balise SPIP dans un squelette ? Ou bien je me trompe quelque part ?
Du côté des limitations, j'ai ajouté ainsi que tu l'as énoncé dans le corps du texte, que les formulaires ainsi gérés ne peuvent pas utiliser les saisies.
Par ailleurs, cette doc me permet de comprendre l'opposition à cette balise : ce n'est pas tant qu'elle ne puisse être utilisée pour tous les projets existants, mais en l'état, les limitations diminuent le potentiel d'adaptation ou d'extension d'un développement y faisant appel (un peu d'utilisation aussi à cause des saisies). En cet aspect, son usage induirait une régression fonctionnelle. De ce fait, l'état "en l'état" ne me semble pas stable...
Pour ta Question :
pendant un moment dans Association2, le 2eme argument valait 'configurer_plugin'. ça correspondait à quoi ? (cf [->Connexion · GitLab])}
c'était une version où le compilateur ne savait pas comprendre tout seul qu'il fallait utiliser "configurer_plugin", à présent il sait le faire.
Yeah, les formulaires CVT deviennent un peu moins barbares avec la simpliciation de ACTION_FORMULAIRE ...
Vis a vis des débutants je me souviens aussi qu'un intérêt de CONFIGURER_METAS est de permettre la création d'un formulaire de config SANS faire de PHP.
Pourtant, le seul moyen de récupérer les valeurs est de coder en PHP (dans association, ça se fait soit via un accés à $_GLOBALS soit via lire_config).
Ne faudrait il pas pouvoir accéder à ces valeurs via une balise SPIP dans un squelette ?
Ce qui le permet c'est la balise #CONFIG, mais ça ne marche que pour la table des metas standard et je réalise que j'aurais dû l'étendre aux nouvelles tables des métas. Je vais voir s'il y a un moyen de s'en tirer quand même en l'état.
Du côté des limitations, j'ai ajouté ainsi que tu l'as énoncé dans le corps du texte, que les formulaires ainsi gérés ne peuvent pas utiliser les saisies.
Là on tombe sur un pb plus général: les balises de SPIP correspond à ce qu'on appelle des macros d'habitude, mais ne sont implémentées comme telles, du coup ça complexifie inutilement un pb comme celui-là. Quitte à bosser là-dessus, je préférerais intervenir sur le pb en amont.
Par ailleurs, cette doc me permet de comprendre l'opposition à cette balise : ce n'est pas tant qu'elle ne puisse être utilisée pour tous les projets existants, mais en l'état, les limitations diminuent le potentiel d'adaptation ou d'extension d'un développement y faisant appel (un peu d'utilisation aussi à cause des saisies). En cet aspect, son usage induirait une régression fonctionnelle. De ce fait, l'état "en l'état" ne me semble pas stable...
Elle est stable en ce sens que c'est une bonne base de départ. On peut essayer de l'étendre, mais il est clair que CFG est de mon point de vue trop laxiste dans sa sémantique: c'est pour ça qu'il est devenu inutilement énorme. Je demande à voir le pourcentage d'utilisations de CFG qui ont vraiment besoin de plus que ce que je propose (hormis le #CONFIG ci-dessus qui est effectivement un oubli gênant).
#CONFIG{truc} permet de lire la meta truc de spip_meta #CONFIG{/xxxx/truc} permet de lire la meta truc de la table spip_xxxx #CONFIG{truc} est équivalent à #CONFIG{/meta/truc}
la fonction support aussi les meta serializee créées par CFG : #CONFIG{truc/chose} lit la valeur chose du tableau serializé enregistré dans la meta truc de spip_meta #CONFIG{/xxxx/truc/chose} lit la valeur chose du tableau serializé enregistré dans la meta truc de la table spip_xxxx
Je propose de l'intégrer au core, cela permettrait un support transversal et générique de tous les types de meta, indépendamment du mode de création.
* cedric.morin@yterium.com tapuscrivait, le 09/08/2010 10:23:
Vis a vis des débutants je me souviens aussi qu'un intérêt de CONFIGURER_METAS est de permettre la création d'un formulaire de config SANS faire de PHP.
Pourtant, le seul moyen de récupérer les valeurs est de coder en PHP (dans association, ça se fait soit via un accés à $_GLOBALS soit via lire_config).
Ne faudrait il pas pouvoir accéder à ces valeurs via une balise SPIP dans un squelette ?
Ce qui le permet c'est la balise #CONFIG, mais ça ne marche que pour la table des metas standard et je réalise que j'aurais dû l'étendre aux nouvelles tables des métas. Je vais voir s'il y a un moyen de s'en tirer quand même en l'état.
#CONFIG{truc} permet de lire la meta truc de spip_meta #CONFIG{/xxxx/truc} permet de lire la meta truc de la table spip_xxxx #CONFIG{truc} est équivalent à #CONFIG{/meta/truc}
la fonction support aussi les meta serializee créées par CFG : #CONFIG{truc/chose} lit la valeur chose du tableau serializé enregistré dans la meta truc de spip_meta #CONFIG{/xxxx/truc/chose} lit la valeur chose du tableau serializé enregistré dans la meta truc de la table spip_xxxx
Je propose de l'intégrer au core, cela permettrait un support transversal et générique de tous les types de meta, indépendamment du mode de création.
Il me semble qu'il manque la gestion de la valeur par défaut : #CONFIG{truc/chose,pardefaut}
Oui d'accord: il faut absolument éviter les fork dans les surcharges, donc si c'est une intersection commune avec tous les cas de figure il faut l'entériner.
Juste une petite remarque ergonomique. Ne pourrait-on pas avoir l'icône ( tournevis et clé) en rouge quand il s'agit d'une configuration "metas" et en bleu quand il s'agit de CFG?
J'ai mis du temps pour comprendre que lorsque je modifiais un formulaire avec cette méthode, je n'étais pas sous CFG.. Comme ce plugin existe encore et qu'il ne va pas disparaitre tout de suite, ce serait plus simple et éviterait de poser autant de questions que je m'en suis posé ou que j'en ais posées à Commito ( d'autant plus si on a d'autres plugins qui tournent avec CFG)
J'allais écrire suite au commit qu'il faudrait définitivement arrêter d'utiliser ces styles css inline qui ont certes l'avantage de la rapidité, mais sont pénibles à gérer au long cours.
Mais je vois que la discussion qui s'en suit en est l'illustration même.
Dans ce cas précis, il faut se contenter d'ajouter une classe CSS sur l'objet pour le différencier dans le cas CFG et non-CFG, ce qui permet ensuite :
- de styler correctement en fonction de la couleur de l'espace privé si besoin
- éventuellement de ne pas différencier, libre à chacun de le faire ensuite sur ses installations.
Je reviens sur configurer metas et son cas d'utilisation le plugin association.
Je dois rater un truc dans l'histoire car ça ne marche pas encore pour moi.
J'ai un SPIP 2.1.1 et association2 d'installés
Je constate que le plugin possède les 2 fichiers configurer_metas
présents dans le trunk. Par sécurité j'ai recopié les données comme
indiqué sur http://www.spip-contrib.net/CONFIGURER_METAS
J'ai trouvé un bogue avec php5.3 qui n'accepte pas func_get_args() en
tant qu'argument de fonctions (le correctif arrive sous peu)
Le formulaire est bien affiché depuis ?exec=associations, un
?page=tables:associations_metas me donne bien des valeurs pour
base_version et charset. La phase charger semble fonctionner vu qu'un
echo dedans s'affiche.
Mais apres verifier et traiter ne semblent pas bosser vu que mon
formulaire reste toujours vide à la fin et je ne vois jamais
s'afficher mes echos de debug.
Suite au conseil fournit je suis passé en 2.1.2 et cela ne change rien
au comportement.
Comme je ne vois pas trop comment le code dans l'ensemble se passe, je
ne sais pas trop où mettre mes points d'arrets pour voir où ça casse.