Ça me gène un peu ça, parce qu'on perd le coté générique de base_ si chacun commence à mettre des exceptions. Il faut réfléchir à quelque chose de mieux pour ça.
Ça me gène un peu ça, parce qu'on perd le coté générique de base_ si chacun commence à mettre des exceptions. Il faut réfléchir à quelque chose de mieux pour ça.
Le côté générique, c'est que si un modèle a besoin de labels spécifiques au lieu d'un label commun, il suffit qu'il rajoute son nom ici.
Avantage : pas besoin de modifier les saisies déjà existantes dans des fonds de CFG (en rajoutant un paramètre à chaque #SAISIE)
Inconvénient : tout nouveau modèle de saisie doit se rajouter dans ce match s'il est concerné.
J'ai pensé à une autre solution plus générique, mais plus complexe :
chaque modèle de saisie serait en fait constitué de 2 fichiers :
- un fichier qui renverrait rien ou un espace pour servir de condition au champ label général
- le fichier actuel
* Matthieu Marcillaud tapuscrivait, le 01/09/2009 13:51:
Ça me gène un peu ça, parce qu'on perd le coté générique de base_ si
chacun commence à mettre des exceptions. Il faut réfléchir à quelque
chose de mieux pour ça.
Le côté générique, c'est que si un modèle a besoin de labels spécifiques
au lieu d'un label commun, il suffit qu'il rajoute son nom ici.
Nope, ça ne marche pas : mes saisies persos n'ont rien à faire dedans, même si j'ai des listes radio…
J'ai pensé à une autre solution plus générique, mais plus complexe :
chaque modèle de saisie serait en fait constitué de 2 fichiers :
- un fichier qui renverrait rien ou un espace pour servir de condition
au champ label général
- le fichier actuel
C'est pas top non plus…
Ça concerne quels type de champs de ne pas avoir de «for» sur ce label ? juste les radio ? ou les radio et certains checkbox ? On peut peut être imaginer que toutes les saisies au nom (pré|suf)fixées de «choix» sont comme ça ? (pour reprendre le nom de la class css des formulaires CVT), et on rennomme «oui_non» en «choix_oui_non» (un peu lourdingue tout de même).
Autre possibilité, faire comme Cédric, un fichier optionnel .xml de paramètres optionnels pour chaque saisie, lu par base_ . Dans ce cas, ça devient lourd et complexe pour les utilisateurs (enfin les gens ne semblent pas se plaindre de compositions non plus) vu que c'est surtout des développeurs qui utilisent ça. Cependant, si chaque plugin invente son truc, on n'a pas fini.
* Matthieu Marcillaud tapuscrivait, le 01/09/2009 19:41:
Le 01/09/2009 19:27, RealET a écrit :
* Matthieu Marcillaud tapuscrivait, le 01/09/2009 13:51:
Ça me gène un peu ça, parce qu'on perd le coté générique de base_ si
chacun commence à mettre des exceptions. Il faut réfléchir à quelque
chose de mieux pour ça.
Le côté générique, c'est que si un modèle a besoin de labels spécifiques
au lieu d'un label commun, il suffit qu'il rajoute son nom ici.
Nope, ça ne marche pas : mes saisies persos n'ont rien à faire dedans, même si j'ai des listes radio…
J'ai pensé à une autre solution plus générique, mais plus complexe :
chaque modèle de saisie serait en fait constitué de 2 fichiers :
- un fichier qui renverrait rien ou un espace pour servir de condition
au champ label général
- le fichier actuel
C'est pas top non plus…
Ça concerne quels type de champs de ne pas avoir de «for» sur ce label ? juste les radio ? ou les radio et certains checkbox ?
Je ne sais pas. J'ai pas une page qui teste toutes les saisies.
Par contre, d'après ce que j'en ai compris, ça concernerait toutes les saisies qui génèrent des labels spécifiques en plus du général.
Donc, avec une recherche rapide de <label dans les saisies/ ça donne :
case.html
checkbox.html
oui_non.html
radio.html
On peut peut être imaginer que toutes les saisies au nom (pré|suf)fixées de «choix» sont comme ça ? (pour reprendre le nom de la class css des formulaires CVT), et on rennomme «oui_non» en «choix_oui_non» (un peu lourdingue tout de même).
Efficace, mais faudrait faire évoluer tous les squelettes utilisant ces saisies...
Autre possibilité, faire comme Cédric, un fichier optionnel .xml de paramètres optionnels pour chaque saisie, lu par base_ . Dans ce cas, ça devient lourd et complexe pour les utilisateurs (enfin les gens ne semblent pas se plaindre de compositions non plus) vu que c'est surtout des développeurs qui utilisent ça. Cependant, si chaque plugin invente son truc, on n'a pas fini.
Entre un .xml et un #CHEMIN{saisies/#ENV{type_saisie}_SansLabelGenerique}, c'est la 2e solution que je choisirais pour ma part : beaucoup plus simple à mettre en œuvre.
Entre un .xml et un #CHEMIN{saisies/#ENV{type_saisie}_SansLabelGenerique}, c'est la 2e
solution que je choisirais pour ma part : beaucoup plus simple à mettre
en œuvre.
Je vois surtout le jour ou label/pas_label ne sera pas la seule chose à modifier. Dans ces cas là un xml est bien plus extensible. Il reste aussi la possibilité d'un fichier de fonctions associé à la saisie, qui pourrait définir aussi des informations. Mais ça m'embête vraiment cette complication.