Le #formulaire_charter a perdu son role de template #4783

Open
opened 1 year ago by cerdic · 3 comments
cerdic commented 1 year ago
Owner

J'avais pas vu passer (ou pas bien vu) le refactoring.
Je comprends bien que ça a amélioré la maintenabilité et lisibilité du code, mais on a perdu complètement le rôle de "hop je prend le code pour ce type de champ, je colle dans mon formulaire et ça marche":

Avant on avait par exemple pour le select:

				#SET{name,select}#SET{obli,''}#SET{defaut,''}#SET{erreurs,#ENV**{erreurs}|table_valeur{#GET{name}}}
				<div class="editer editer_[(#GET{name})][ (#GET{obli})][ (#GET{erreurs}|oui)erreur]">
					<label for="#GET{name}">[(#GET{fl}|concat{':label_',#GET{name}}|_T)]</label>[
					<span class='erreur_message'>(#GET{erreurs})</span>
					]<select name="#GET{name}" class="select" id="#GET{name}">
						#SET{val,oui}
						<option value="#GET{val}"[(#ENV{#GET{name},#GET{defaut}}|=={#GET{val}}|oui)selected="selected"]>[(#GET{fl}|concat{':label_',#GET{name},'_',#GET{val}}|_T)]</option>
						#SET{val,non}
						<option value="#GET{val}"[(#ENV{#GET{name},#GET{defaut}}|=={#GET{val}}|oui)selected="selected"]>[(#GET{fl}|concat{':label_',#GET{name},'_',#GET{val}}|_T)]</option>
					</select>
				</div>

Il suffisait de faire un #SET{fl,monfichierlangue} en début de formulaire, puis de mettre mettre les val qui vont bien dans les options, et tout était prêt à l'emploi, juste à renseigner les chaines de langues.

Maintenant on a

				#SET{name,saisie_3}#SET{obli,''}#SET{defaut,''}#SET{erreurs,#ENV**{erreurs/#GET{name}}}#SET{id,#GET{name}|concat{#ENV{suffixe}}}
				<div class="editer editer_[(#GET{name})][ (#GET{obli})][ (#GET{erreurs}|oui)erreur]">
					<label for="#GET{id}"><:charter:label_select:></label>[
					<span class='erreur_message'>(#GET{erreurs})</span>
					]<select name="#GET{name}" class="select" id="#GET{id}">
						#SET{val,oui}
						<option value="#GET{val}"[(#ENV{#GET{name},#GET{defaut}}|=={#GET{val}}|oui)selected="selected"]><:charter:label_valeur_oui_long:></option>
						#SET{val,non}
						<option value="#GET{val}"[(#ENV{#GET{name},#GET{defaut}}|=={#GET{val}}|oui)selected="selected"]><:charter:label_valeur_non_long:></option>
					</select>
				</div>

On voit que tous les libellés sont des chaines de langue en dur, qu'il faut donc reprendre à la main une par une.

En plus on se retrouve avec le #ENV{suffixe} qui n'a de sens que pour ce formulaire, pas quand on colle l'exemple dans un autre formulaite.

Bref, je vois bien la raison qui a guidée ce refactoring, mais du coup on a perdu l'autre usage qui était "des snippets de code prêt à l'emploi pour composer son propre formulaire"

(et je vais donc devoir me forker le formulaire pour en refaire une version prête à l'emploi... :( )

J'avais pas vu passer (ou pas bien vu) le refactoring. Je comprends bien que ça a amélioré la maintenabilité et lisibilité du code, mais on a perdu complètement le rôle de "hop je prend le code pour ce type de champ, je colle dans mon formulaire et ça marche": Avant on avait par exemple pour le select: ``` #SET{name,select}#SET{obli,''}#SET{defaut,''}#SET{erreurs,#ENV**{erreurs}|table_valeur{#GET{name}}} <div class="editer editer_[(#GET{name})][ (#GET{obli})][ (#GET{erreurs}|oui)erreur]"> <label for="#GET{name}">[(#GET{fl}|concat{':label_',#GET{name}}|_T)]</label>[ <span class='erreur_message'>(#GET{erreurs})</span> ]<select name="#GET{name}" class="select" id="#GET{name}"> #SET{val,oui} <option value="#GET{val}"[(#ENV{#GET{name},#GET{defaut}}|=={#GET{val}}|oui)selected="selected"]>[(#GET{fl}|concat{':label_',#GET{name},'_',#GET{val}}|_T)]</option> #SET{val,non} <option value="#GET{val}"[(#ENV{#GET{name},#GET{defaut}}|=={#GET{val}}|oui)selected="selected"]>[(#GET{fl}|concat{':label_',#GET{name},'_',#GET{val}}|_T)]</option> </select> </div> ``` Il suffisait de faire un `#SET{fl,monfichierlangue}` en début de formulaire, puis de mettre mettre les val qui vont bien dans les options, et tout était prêt à l'emploi, juste à renseigner les chaines de langues. Maintenant on a ``` #SET{name,saisie_3}#SET{obli,''}#SET{defaut,''}#SET{erreurs,#ENV**{erreurs/#GET{name}}}#SET{id,#GET{name}|concat{#ENV{suffixe}}} <div class="editer editer_[(#GET{name})][ (#GET{obli})][ (#GET{erreurs}|oui)erreur]"> <label for="#GET{id}"><:charter:label_select:></label>[ <span class='erreur_message'>(#GET{erreurs})</span> ]<select name="#GET{name}" class="select" id="#GET{id}"> #SET{val,oui} <option value="#GET{val}"[(#ENV{#GET{name},#GET{defaut}}|=={#GET{val}}|oui)selected="selected"]><:charter:label_valeur_oui_long:></option> #SET{val,non} <option value="#GET{val}"[(#ENV{#GET{name},#GET{defaut}}|=={#GET{val}}|oui)selected="selected"]><:charter:label_valeur_non_long:></option> </select> </div> ``` On voit que tous les libellés sont des chaines de langue en dur, qu'il faut donc reprendre à la main une par une. En plus on se retrouve avec le `#ENV{suffixe}` qui n'a de sens que pour ce formulaire, pas quand on colle l'exemple dans un autre formulaite. Bref, je vois bien la raison qui a guidée ce refactoring, mais du coup on a perdu l'autre usage qui était "des snippets de code prêt à l'emploi pour composer son propre formulaire" (et je vais donc devoir me forker le formulaire pour en refaire une version prête à l'emploi... :( )
Poster
Owner
(Je parle de ce formulaire https://git.spip.net/spip/dev/src/branch/master/formulaires/charter.html )
b_b commented 1 year ago
Owner

Il suffisait de faire un #SET{fl,monfichierlangue} en début de formulaire, puis de mettre mettre les val qui vont bien dans les options, et tout était prêt à l'emploi, juste à renseigner les chaines de langues.

Bref, je vois bien la raison qui a guidée ce refactoring, mais du coup on a perdu l'autre usage qui était "des snippets de code prêt à l'emploi pour composer son propre formulaire"

Je découvre avec ta remarque que cet usage était possible,je ne crois pas que c'était documenté, et même moi qui suit "un peu" ce qui se passe j'étais passé à côté. Bref, je pense qu'il n'y pas grand monde qui savait ça et en avait l'usage, ça minimise l'impact donc.

Mais peut-être qu'il est possible de satisfaire les deux besoins sans perdre tout le travail effectué par @tcharlss sur cette partie ?

> Il suffisait de faire un #SET{fl,monfichierlangue} en début de formulaire, puis de mettre mettre les val qui vont bien dans les options, et tout était prêt à l'emploi, juste à renseigner les chaines de langues. > Bref, je vois bien la raison qui a guidée ce refactoring, mais du coup on a perdu l'autre usage qui était "des snippets de code prêt à l'emploi pour composer son propre formulaire" Je découvre avec ta remarque que cet usage était possible,je ne crois pas que c'était documenté, et même moi qui suit "un peu" ce qui se passe j'étais passé à côté. Bref, je pense qu'il n'y pas grand monde qui savait ça et en avait l'usage, ça minimise l'impact donc. Mais peut-être qu'il est possible de satisfaire les deux besoins sans perdre tout le travail effectué par @tcharlss sur cette partie ?
Owner

Je comprends bien le besoin, il m'arrive parfois de chercher aussi une référence pour copier-coller des bouts de codes de formulaire.

Mais quand j'ai refactoré ce formulaire je l'ai envisagé avant tout comme un support à la documentation : ce qui importait c'était le markup généré, le rendu des éléments de formulaire, les variations possibles d'un même type de saisie, etc.

Dans ce cas précis, obligé d'ajouter des particularités propres à ce formulaire : le #ENV{variante} dans les ids, etc.

Je ne vois donc pas comment concilier facilement les 2 besoins dans un même formulaire, à mon avis ce sont 2 choses différentes.

En complément, pour des snippets de code prêts à copier-coller il faudrait un formulaire orienté "code génériqaue à copier-coller" : #FORMULAIRE_CHARTER_SNIPPETS ou un truc comme ça.

Je comprends bien le besoin, il m'arrive parfois de chercher aussi une référence pour copier-coller des bouts de codes de formulaire. Mais quand j'ai refactoré ce formulaire je l'ai envisagé avant tout comme un support à la documentation : ce qui importait c'était le markup généré, le rendu des éléments de formulaire, les variations possibles d'un même type de saisie, etc. Dans ce cas précis, obligé d'ajouter des particularités propres à ce formulaire : le \#ENV{variante} dans les ids, etc. Je ne vois donc pas comment concilier facilement les 2 besoins dans un même formulaire, à mon avis ce sont 2 choses différentes. En complément, pour des snippets de code prêts à copier-coller il faudrait un formulaire orienté "code génériqaue à copier-coller" : #FORMULAIRE_CHARTER_SNIPPETS ou un truc comme ça.
b_b added the
amélioration
label 3 months ago
b_b added this to the spip-4.2 milestone 3 months ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.