Oui, on peut ré-écrire tous les appels aux fonctions c,v,t et aux pipelines correspondants pour tacher de retomber sur nos pieds. Au prix d'une redondance de code et des appels, qui découle logiquement de la redondance entre #FORMULAIRE_CONFIGURER_PLUGIN{xx,truc} et #FORMULAIRE_CONFIGURER_TRUC
Je vais réfléchir encore à tout ça. Ce que je retiens de ce point précis de la discussion c'est qu'il y a peut-être la possibilité de dispenser d'écrire la balise "ACTION_FORMULAIRE", ce qui serait une bonne nouvelle.
Si on pouvait éviter de casser CFG et CVT du même coup ce serait cool
Autrement dit, avant de changer ça, il serait bien de recenser les usages de CVT, pour garantir que ce qu'on met à la place marche dans tous les coups.
Si nécessaire, on peut lancer une collection des usages de CVT pour permettre de valider une évolution dans tous les cas, car il y en a la aussi de nombreux et divers...
Mais je répète que je ne casse rien, seulement proposer qqch qui soit plus simple et moins coûteux dans un nombre suffisamment intéressant de cas. S'agissant de ACTION_FORMULAIRE, l'idée serait de dire que cette balise ne fait plus rien car le boulot serait fait en amont.
Concrètement, j'écris un squelette pour un site dans mon dossier squelettes/
Faire un plugin juste pour le formulaire de configuration, ça veut dire disperser les éléments qui vont ensemble (les squelettes/ ne marchent pas sans la configuration, qui n'a de sens qu'avec les squelettes/)
Tout mettre dans un plugin, ça veut dire qu'on ne peut plus travailler dans le dossier squelettes/ ?
Il y a un point particulier sur lequel tu n'as pas répondu, et qui me parait quand même gênant, c'est que dans ta proposition, on se retrouve avec deux façons d'appeler le squelette formulaires/configurer_truc.html, à savoir
#FORMULAIRE_CONFIGURER_TRUC et #FORMULAIRE_CONFIGURER_PLUGIN{machin,truc}
qui ne sont pas équivalentes, et dont le seul moyen de discrimination est la lecture du code php associé ...
Comment resoud-on ce problème ?
Tout mettre dans un plugin, ça veut dire qu'on ne peut plus travailler dans le dossier squelettes/ ?
J'ai bien précisé "pour les squelettes avec configuration". Je pense que c'est un effort d'organisation qui n'est pas énorme et dont la preuve par l'absurde de l'utilité a été donnée dans la difficulté à sortir proprement des squelettes std hors du noyau.
Il y a un point particulier sur lequel tu n'as pas répondu, et qui me parait quand même gênant, c'est que dans ta proposition, on se retrouve avec deux façons d'appeler le squelette formulaires/configurer_truc.html, à savoir
#FORMULAIRE_CONFIGURER_TRUC et #FORMULAIRE_CONFIGURER_PLUGIN{machin,truc}
qui ne sont pas équivalentes, et dont le seul moyen de discrimination est la lecture du code php associé ...
Comment resoud-on ce problème ?
Je n'ai pas répondu parce que je ne perçois pas ça comme un problème. Le fait que plusieurs balises dynamiques puissent utiliser un même squelette mais en lui faisant cracher des résultats différents n'a rien de choquant en soi. Tu sais aussi bien que moi qu'au final toute cette mécanique est une inclusion, rendue seulement un peu plus compliquée par une connaissance tardive du contexte d'inclusion. Je trouve plutôt bon signe qu'un code HTML ne soit plus nécessairement lié à un unique code PHP capable de l'utiliser.
> Tout mettre dans un plugin, ça veut dire qu'on ne peut plus
> travailler dans le dossier squelettes/ ?
J'ai bien précisé "pour les squelettes avec configuration". Je pense
que c'est un effort d'organisation qui n'est pas énorme et dont la
preuve par l'absurde de l'utilité a été donnée dans la difficulté à
sortir proprement des squelettes std hors du noyau.
Même dans le cas où l'on n'a que des plugins, est-ce qu'il n'y avait
pas aussi la question de pouvoir organiser les formulaires en groupant
les options suivant les fonctionnalités et non pas par plugin ?
