le plugin bandeau implémente un refactoring des configurations du core pour l'identité, les préférences et la langue : http://zone.spip.org/trac/spip-zone/browser/plugins/bandeau/formulaires
Je ne peux pas utiliser #CONFIGURER_META pour ces formulaires,
car comme ils sont dans un plugin, les meta sont obligatoirement lues et écrites dans la table bandeau_metas.
La même question se pose si je veux refaire la configuration en formulaire des urls, qui est actuellement dans l'ancien format : http://zone.spip.org/trac/spip-zone/browser/core/plugins/urls_etendues/configuration/type_urls.php
Il n'est pas question de stocker l'information du type d'url dans une table des meta séparée car c'est une configuration intrinsèque à SPIP
Si je veux le réécrire avec #CONFIGURER_META, et que les meta sont stockées dans une table séparée, un webmestre ne pourra plus surcharger le formulaire html de configuration dans son dossier squelettes/
Un cas concrêt de ce besoin est de surcharger le formulaire pour interdire de désactiver l'utilisation des articles d'accueil (oui,
avant de mettre un site dans les mains de certains utilisateurs il *faut* verrouiller certains réglages sauf à passer son temps à faire du support. Et non, la formation ne suffit pas, et c'est un autre débat).
Donc en pratique on perd la possibilité de surcharge du squelette, ce qui est tout de même un fondamental de SPIP. Sauf à ré-écrire les fonctions charger() et traiter(), ce qui nous ramène à l'inutilité de #CONFIGURER_META
Le problème de fond que j'avais déjà soulevé et que j'illustre ici avec des cas concrets est que #CONFIGURER_META décide si il faut stocker dans spip_meta ou dans une table meta séparée sur la base de l'emplacement du squelette du formulaire (dans un plugin ou non). Ce comportement est rigide et ne correspond pas aux usages et besoins.
En pratique, il ne permet pas d'utiliser #CONFIGURER_META dans de nombreux cas, et, pire, si on l'utilise on ferme des possibilités d'utilisation.
Ou alors il faut toujours stocker dans la table des meta de SPIP, pour ne pas être bloqué à un moment ou à un autre, ce qui nous ramène à l'inutilité de #CONFIGURER_META en l'état.
Concrètement ? Et cela ne résoudrait que ce cas là de personnalisation.
Si le webmestre veut personnaliser le formulaire pour ajouter une option qu'il utilise ensuite dans son squelette ?
Je donne un exemple de besoin de surcharge, mais la question fondamentale est bien : supprime-t-on le droit de surcharger les formulaires de configuration de SPIP et des plugins ?
Si je veux le réécrire avec #CONFIGURER_META, et que les meta sont stockées dans une table séparée, un webmestre ne pourra plus surcharger le formulaire html de configuration dans son dossier squelettes/
Un cas concrêt de ce besoin est de surcharger le formulaire pour interdire de désactiver l'utilisation des articles d'accueil (oui,
avant de mettre un site dans les mains de certains utilisateurs il *faut* verrouiller certains réglages sauf à passer son temps à faire du support. Et non, la formation ne suffit pas, et c'est un autre débat).
Même si je suis d'accord sur l'analyse présentée dans ton message, pourquoi ne pas gérer cet aspect particulier avec des autorisations, plutôt ?
Concrètement ? Et cela ne résoudrait que ce cas là de personnalisation.
Si le webmestre veut personnaliser le formulaire pour ajouter une option qu'il utilise ensuite dans son squelette ?
Qu'il ajouterait dans le formulaire de config de Compositions ? Etrange...
Je donne un exemple de besoin de surcharge, mais la question fondamentale est bien : supprime-t-on le droit de surcharger les formulaires de configuration de SPIP et des plugins ?
Oui, je sais bien, c'est pour ça que j'indiquais que le suis d'accord pour tout le reste de ton mail...
Si je veux le réécrire avec #CONFIGURER_META, et que les meta sont stockées dans une table séparée, un webmestre ne pourra plus surcharger le formulaire html de configuration dans son dossier squelettes/
Un cas concrêt de ce besoin est de surcharger le formulaire pour interdire de désactiver l'utilisation des articles d'accueil (oui,
avant de mettre un site dans les mains de certains utilisateurs il *faut* verrouiller certains réglages sauf à passer son temps à faire du support. Et non, la formation ne suffit pas, et c'est un autre débat).
Même si je suis d'accord sur l'analyse présentée dans ton message, pourquoi ne pas gérer cet aspect particulier avec des autorisations, plutôt ?
Concrètement ? Et cela ne résoudrait que ce cas là de personnalisation.
Si le webmestre veut personnaliser le formulaire pour ajouter une option qu'il utilise ensuite dans son squelette ?
Qu'il ajouterait dans le formulaire de config de Compositions ? Etrange...
Par exemple pour définir une composition par défaut, ou gérer des droits en designant les webmestres qui ont le droit de modifier les compositions etc ... Il y a toujours plein de scenari qu'on imagine pas au départ.
Je donne un exemple de besoin de surcharge, mais la question fondamentale est bien : supprime-t-on le droit de surcharger les formulaires de configuration de SPIP et des plugins ?
Oui, je sais bien, c'est pour ça que j'indiquais que le suis d'accord pour tout le reste de ton mail...
