[SPIP Zone] Formidable : supprimer un champ à la saisie tout en gardant l'historique des réponses

maieul · Mai 7, 2019, 3:55

Holla,

il m'arrive parfois de devoir supprimer un ancien champ dans un formulaire formidable. Pour autant, j'aimerais conservé l'historique des réponses apportées à ce champ par le passé. Actuellement ce n'est pas possible.

On s'en sort avec des affiche_si un peu moche (du style @champ_xxx@="blabla". Mais c'est vraiment cradingue.

Il faudrait un mécanisme général pour cela.

Je vois deux possibilités:
- une option par par saisie
- une option globale au niveau de chaque formulaire formidable, proposant d'ignorer certains champs.

Cette seconde option à ma préférence (moins de modif dans saisies, cohérence, etc.). Mais j'aiemrauis avoir votre avis avant.

Merci d'avance

Maïeul

maieul · Mai 7, 2019, 4:14

Le 07/05/2019 à 17:55, Maïeul a écrit :

Holla,

il m'arrive parfois de devoir supprimer un ancien champ dans un formulaire formidable. Pour autant, j'aimerais conservé l'historique des réponses apportées à ce champ par le passé. Actuellement ce n'est pas possible.

On s'en sort avec des affiche_si un peu moche (du style @champ_xxx@="blabla". Mais c'est vraiment cradingue.

Il faudrait un mécanisme général pour cela.

Je vois deux possibilités:
- une option par par saisie
- une option globale au niveau de chaque formulaire formidable, proposant d'ignorer certains champs.

Cette seconde option à ma préférence (moins de modif dans saisies, cohérence, etc.). Mais j'aiemrauis avoir votre avis avant.

Merci d'avance

Maïeul

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Suis-je bete: on pourrait faire un mécanisme dans saisies pour avoir une option dans toutes les saisies.

_dd · Mai 7, 2019, 5:51

Cette page est bizarre : https://contrib.spip.net/Service-en-boucle-le-retour

dd

rastapopoulos · Mai 7, 2019, 6:14

Le 07/05/2019 à 18:14, Maïeul a écrit :

Suis-je bete: on pourrait faire un mécanisme dans saisies pour avoir une
option dans toutes les saisies.

C'est le cas pour le champ "position" qui s'ajoute au form de config de
100% des saisies, quand bien même aucune valeur n'est enregistré dans
"options" au final pour ce champ.

Là pour rendre "inactif" une saisie, moi je stockerais bien ça dans
"options" par contre, mais dans tous les cas, c'est bien possible
d'ajouter une saisie de config pour l'ensemble toujours.

Ensuite quand cette option "inactif" est là, faut le prendre en compte
dans l'affichage pour les virer du tableau (le plus mutualisé possible,
quoique du coup est-ce que dans l'affichage d'admin on les utiliserait
celles en inactif ?)

--
RastaPopoulos

maieul · Mai 7, 2019, 8:43

Le 07/05/2019 à 20:14, RastaPopoulos a écrit :

Le 07/05/2019 à 18:14, Maïeul a écrit :

Suis-je bete: on pourrait faire un mécanisme dans saisies pour avoir une
option dans toutes les saisies.

C'est le cas pour le champ "position" qui s'ajoute au form de config de
100% des saisies, quand bien même aucune valeur n'est enregistré dans
"options" au final pour ce champ.

Là pour rendre "inactif" une saisie, moi je stockerais bien ça dans
"options" par contre, mais dans tous les cas, c'est bien possible
d'ajouter une saisie de config pour l'ensemble toujours.

Ensuite quand cette option "inactif" est là, faut le prendre en compte
dans l'affichage pour les virer du tableau (le plus mutualisé possible,
quoique du coup est-ce que dans l'affichage d'admin on les utiliserait
celles en inactif ?)

j'ai un souci avec "inactif", c'est qu'on aussi pour pas mal de saisies une case "désactiver le champ" correspondant à disabled.

Du coup je me demande si le terme "ignoré" serait pas mieux.

Concernant les champs inactifs: dans generer_saisies et verifier_saisies et sans doute d'autre, il faut les virer. Par contre dans le constructeur de saisie, of course, il faut voir.

rastapopoulos · Mai 8, 2019, 9:27

Le 07/05/2019 à 22:43, Maïeul a écrit :

j'ai un souci avec "inactif", c'est qu'on aussi pour pas mal de saisies
une case "désactiver le champ" correspondant à disabled.

Du coup je me demande si le terme "ignoré" serait pas mieux.

Inutilisé ? Masqué ? Non masqué ça fait hidden mais quand même là.

Comme dit hier, ça serait vraiment bien de trouver un terme qui
conviendrait à la fois pour Saisies, Entrées de menu, Noisettes, etc.

Technique : "inutilise"
Label humain : "Désactiver l'utilisation" ?

Pff pas facile à trouver effectivement. Je ne suis pas satisfait non
plus, et je voudrais vraiment un terme commun.

--
RastaPopoulos

RealET · Mai 8, 2019, 9:51

RastaPopoulos a écrit le 08/05/2019 à 11:27 :

Le 07/05/2019 à 22:43, Maïeul a écrit :

j'ai un souci avec "inactif", c'est qu'on aussi pour pas mal de saisies
une case "désactiver le champ" correspondant à disabled.

Du coup je me demande si le terme "ignoré" serait pas mieux.

Inutilisé ? Masqué ? Non masqué ça fait hidden mais quand même là.

Comme dit hier, ça serait vraiment bien de trouver un terme qui
conviendrait à la fois pour Saisies, Entrées de menu, Noisettes, etc.

Technique : "inutilise"
Label humain : "Désactiver l'utilisation" ?

Pff pas facile à trouver effectivement. Je ne suis pas satisfait non
plus, et je voudrais vraiment un terme commun.

Inactivé.

Ce qui est différent de "être inactif" puisque c'est
"avoir été inactivé".

--
RealET

maieul · Mai 8, 2019, 10:44

Le 08/05/2019 à 11:51, RealET a écrit :

RastaPopoulos a écrit le 08/05/2019 à 11:27 :

Le 07/05/2019 à 22:43, Maïeul a écrit :

j'ai un souci avec "inactif", c'est qu'on aussi pour pas mal de saisies
une case "désactiver le champ" correspondant à disabled.

Du coup je me demande si le terme "ignoré" serait pas mieux.

Inutilisé ? Masqué ? Non masqué ça fait hidden mais quand même là.

Comme dit hier, ça serait vraiment bien de trouver un terme qui
conviendrait à la fois pour Saisies, Entrées de menu, Noisettes, etc.

Technique : "inutilise"
Label humain : "Désactiver l'utilisation" ?

Pff pas facile à trouver effectivement. Je ne suis pas satisfait non
plus, et je voudrais vraiment un terme commun.

Inactivé.

Ce qui est différent de "être inactif" puisque c'est
"avoir été inactivé".

oui mais la subtitlié entre "inactif" et "inactivé" est un peu subtile.
Inutilisé me parait mieux.

spip_spipfactory · Mai 8, 2019, 10:45

Le 08/05/2019 à 11:27, RastaPopoulos a écrit :

Le 07/05/2019 à 22:43, Maïeul a écrit :

j'ai un souci avec "inactif", c'est qu'on aussi pour pas mal de saisies
une case "désactiver le champ" correspondant à disabled.

Du coup je me demande si le terme "ignoré" serait pas mieux.

Inutilisé ? Masqué ? Non masqué ça fait hidden mais quand même là.

Comme dit hier, ça serait vraiment bien de trouver un terme qui
conviendrait à la fois pour Saisies, Entrées de menu, Noisettes, etc.

Technique : "inutilise"
Label humain : "Désactiver l'utilisation" ?

Pff pas facile à trouver effectivement. Je ne suis pas satisfait non
plus, et je voudrais vraiment un terme commun.

Synonymes de inactif

--

----
En répondant a ce courriel vous acceptez implicitement la diffusion, l'échange de la conversation, sauf avis contraire clairement exprimé.

RealET · Mai 8, 2019, 11:04

Maïeul a écrit le 08/05/2019 à 12:44 :

oui mais la subtitlié entre "inactif" et "inactivé" est un peu subtile.
Inutilisé me parait mieux.

Dans un premier temps, j'ai trouvé ton mot bien choisi.
Et puis j'ai réalisé que c'était hyper ambigüe entre :
- constaté inutilisé (comme le permet la médiathèque : trouver les documents inutilisés)
- déclaré inutilisé

J'ai pensé à "Archivé".
"À la morgue"
"Indisponible"
"Pour mémoire"
"En stock"
"Non affichable"
"Privé"
"Inutilisable"

--
RealET

cerdic · Mai 8, 2019, 12:13

Je pense que vous tirez un peu dans les coin en étant focalisé par la technique et en oubliant le besoin de l’utilisateur:
supprimer un champ du formulaire (mais sans perdre les anciennes données saisies)

L’interface devrait donc être « supprimer ce champ », tout simplement.

Et ensuite, derrière ça il faut changer le mode de fonctionnement : là où jusqu’ici ça supprimait effectivement le champ de la structure du formulaire et on perdait les données (ou a minima leur sens ?), ça conserverait le champ dans la structure, en y ajoutant un flag ou un statut ou ce que vous voulez pour qu’il n’apparaisse plus nulle part dans le formulaire (que ce soit en édition des champs du formulaire ou en affichage/saisie)

Par contre, dans la visu des réponses au formulaire, les vieux champs « supprimés » continueraient à être affichés si il y a des réponses dessus. Et ça pourrait être là qu’on ait ensuite une option « supprimer les données des champs supprimés » avec confirmation, choix éventuel des champs etc, qui au final aboutirait à une suppression réelle du champ ET de ses données (mais franchement c’est très optionnel)

Donc je pense pas qu’il faille ajouter une n-ième case à cocher au libellé incompréhensible dans les X onglets de configuration de chaque saisie… mais ça empêche pas que la mécanique repose sur une option/flag générique de saisie qui a pour conséquence de faire disparaitre le champ.

Mais attention aussi : un champ « zombie », « fantome » ou « ghost » ne devra pas non plus accepter de nouvelles valeurs en base (ie je supprime le champ, mais un étourdi avait gardé le formulaire ouvert et l’envoie après, ou un petit malin réinjecte du html pour envoyer du contenu sur ce champ qu’il avait vu)

Bises

--
Cédric
Le 8 mai 2019 à 12:44 +0200, Maïeul <maieul@maieul.net>, a écrit :

Le 08/05/2019 à 11:51, RealET a écrit :
> RastaPopoulos a écrit le 08/05/2019 à 11:27 :
> > Le 07/05/2019 à 22:43, Maïeul a écrit :
> > > j'ai un souci avec "inactif", c'est qu'on aussi pour pas mal de saisies
> > > une case "désactiver le champ" correspondant à disabled.
> > >
> > > Du coup je me demande si le terme "ignoré" serait pas mieux.
> >
> > Inutilisé ? Masqué ? Non masqué ça fait hidden mais quand même là.
> >
> > Comme dit hier, ça serait vraiment bien de trouver un terme qui
> > conviendrait à la fois pour Saisies, Entrées de menu, Noisettes, etc.
> >
> > Technique : "inutilise"
> > Label humain : "Désactiver l'utilisation" ?
> >
> > Pff pas facile à trouver effectivement. Je ne suis pas satisfait non
> > plus, et je voudrais vraiment un terme commun.
> >
> Inactivé.
>
> Ce qui est différent de "être inactif" puisque c'est
> "avoir été inactivé".
>
oui mais la subtitlié entre "inactif" et "inactivé" est un peu subtile.
Inutilisé me parait mieux.

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

maieul · Mai 8, 2019, 12:17

il faudrait alors un mécanisme pour restaurer aussi le champ. Peut être
qu'effectivement ce serait plus pertinent.
Le mercredi 08 mai 2019 à 14:13 +0200, Cerdic a écrit :

Je pense que vous tirez un peu dans les coin en étant focalisé par la
technique et en oubliant le besoin de l’utilisateur:
supprimer un champ du formulaire (mais sans perdre les anciennes
données saisies)

L’interface devrait donc être « supprimer ce champ », tout simplement.

Et ensuite, derrière ça il faut changer le mode de fonctionnement : là
où jusqu’ici ça supprimait effectivement le champ de la structure du
formulaire et on perdait les données (ou a minima leur sens ?), ça
conserverait le champ dans la structure, en y ajoutant un flag ou un
statut ou ce que vous voulez pour qu’il n’apparaisse plus nulle part
dans le formulaire (que ce soit en édition des champs du formulaire ou
en affichage/saisie)

Par contre, dans la visu des réponses au formulaire, les vieux champs
« supprimés » continueraient à être affichés si il y a des réponses
dessus. Et ça pourrait être là qu’on ait ensuite une option
« supprimer les données des champs supprimés » avec confirmation,
choix éventuel des champs etc, qui au final aboutirait à une
suppression réelle du champ ET de ses données (mais franchement c’est
très optionnel)

Donc je pense pas qu’il faille ajouter une n-ième case à cocher au
libellé incompréhensible dans les X onglets de configuration de chaque
saisie… mais ça empêche pas que la mécanique repose sur une
option/flag générique de saisie qui a pour conséquence de faire
disparaitre le champ.

Mais attention aussi : un champ « zombie », « fantome » ou « ghost »
ne devra pas non plus accepter de nouvelles valeurs en base (ie je
supprime le champ, mais un étourdi avait gardé le formulaire ouvert et
l’envoie après, ou un petit malin réinjecte du html pour envoyer du
contenu sur ce champ qu’il avait vu)

Bises

--
Cédric
Le 8 mai 2019 à 12:44 +0200, Maïeul <maieul@maieul.net>, a écrit :
> Le 08/05/2019 à 11:51, RealET a écrit :
> > RastaPopoulos a écrit le 08/05/2019 à 11:27 :
> > > Le 07/05/2019 à 22:43, Maïeul a écrit :
> > > > j'ai un souci avec "inactif", c'est qu'on aussi pour pas mal
> > > > de saisies
> > > > une case "désactiver le champ" correspondant à disabled.
> > > >
> > > > Du coup je me demande si le terme "ignoré" serait pas mieux.
> > >
> > > Inutilisé ? Masqué ? Non masqué ça fait hidden mais quand même
> > > là.
> > >
> > > Comme dit hier, ça serait vraiment bien de trouver un terme qui
> > > conviendrait à la fois pour Saisies, Entrées de menu, Noisettes,
> > > etc.
> > >
> > > Technique : "inutilise"
> > > Label humain : "Désactiver l'utilisation" ?
> > >
> > > Pff pas facile à trouver effectivement. Je ne suis pas satisfait
> > > non
> > > plus, et je voudrais vraiment un terme commun.
> > >
> > Inactivé.
> >
> > Ce qui est différent de "être inactif" puisque c'est
> > "avoir été inactivé".
> >
> oui mais la subtitlié entre "inactif" et "inactivé" est un peu
> subtile.
> Inutilisé me parait mieux.
>
> ----
> spip-zone@rezo.net -
> https://listes.rezo.net/mailman/listinfo/spip-zone

rastapopoulos · Mai 8, 2019, 12:37

Le 08/05/2019 à 14:13, Cerdic a écrit :

L’interface devrait donc être « supprimer ce champ », tout simplement.

Je ne suis absolument pas d'accord, c'est une toute autre fonctionnalité.

Ce que tu dis a effectivement un sens pour le bouton "supprimer ce
champ" *qui existe déjà*, donc tout ce que tu décris correspondrait à
une amélioration de cette fonction existante.

Moi je parle d'une fonctionnalité, qui est un besoin extrêmement courant
d'après mes retours utilisateurs et même l'utilisation que j'en ai
moi-même, et qui vaut à la fois pour Saisies, pour des Entrées de menus,
pour des Noisettes, etc : comme un statut binaire : pouvoir
activer/désactiver un morceau SANS supprimer rien du tout, et pouvoir le
réactiver une semaine après si on veut, à loisir.

Car actuellement, si on veut ne plus afficher un morceau d'un
formulaire, une entrée de menu (qui peut contenir tout un sous-menu et
en cascade !), ou des noisettes : on doit complètement supprimer, et le
jour où on veut les remettre, il faut tout reconfigurer à zéro.

Là on parle bien d'un besoin de statut binaire. Par défaut quand on
ajoute c'est toujours actif (en ligne quoi), mais on doit pouvoir pour
tous ces plugins, le désactiver/réactiver. Et moi j'aimerais avec les
mêmes termes humains et techniques, histoire d'avoir une cohérence
partout, que ce soit API et ergonomique.

--
RastaPopoulos

cerdic · Mai 8, 2019, 1:55

Le 8 mai 2019 à 14:37 +0200, RastaPopoulos <rastapopoulos@spip.org>, a écrit :

Le 08/05/2019 à 14:13, Cerdic a écrit :
> L’interface devrait donc être « supprimer ce champ », tout simplement.

Je ne suis absolument pas d’accord, c'est une toute autre fonctionnalité.

Excuse moi, mais relit le titre du thread !
« Formidable : supprimer un champ à la saisie tout en gardant l’historique des réponses »

T’as le droit de pas être d’accord avec autre chose, mais ça tombe bien j’en parlais pas

Plus sérieusement ce fil me fait réagir, car une nouvelle fois je vois qu’au pretexte/en raison de vouloir avoir/faire une super API technique en dessous pour faire tout et son contraire, on va encore avoir une interface moisie car calquée sur l’API.

Je vous refais pas le discours sur les saisies, vous en avez par dessus la tête, mais en voilà encore une parfaite illustration.

Donc bref, faites ce que vous voulez dans les saisies, mais n’allez pas cacher au fond d’une boite de configuration avec trouze mille options à cocher toutes plus incompréhensibles que les autres la fonctionnalité « supprimer ce champ sans perdre les données » dans Formidable (alors même que le bouton « supprimer ce champ » continuera à tout scratcher sauvagement, ce qu’on ne devrait jamais faire nulle part)

Je te laisse continuer à discuter d’autre chose dans ce fil

—
Cédric

rastapopoulos · Mai 8, 2019, 2:06

Le 08/05/2019 à 15:55, Cerdic a écrit :

Plus sérieusement ce fil me fait réagir, car une nouvelle fois je vois
qu’au pretexte/en raison de vouloir avoir/faire une super API technique
en dessous pour faire tout et son contraire, on va encore avoir une
interface moisie car calquée sur l’API.

Je ne vois absolument pas à quel moment il a été question de ça.

Le fait de tout supprimer quand on demande à supprimer, moi ça ne me
choque pas du tout, si c'est bien affiché, au contraire, ça ne fait pas
garder des choses pour rien. Donc le comportement que toi tu décris, je
trouve que c'est une amélioration en plus (et qui peut-être devrait être
optionnelle et pas forcément toujours le cas). Si on veut vraiment
supprimer des choses inutiles, qui n'ont plus lieu d'être, on doit
pouvoir le faire par défaut.

Quand Maieul m'a parlé de ça sur IRC, je n'avais même pas encore vu ce
fil email, et j'ai immédiatement pensé à ce que j'ai décrit parce que
c'est un problème très similaire à ce qu'on m'a demandé et dont moi-même
j'ai eu besoin plein de fois.

Qui n'a absolument rien à voir avec de l'API et une interface calquée
sur de l'API, c'est vraiment n'importe quoi de dire ça. Je le redis : ce
que je décris moi est directement la transcription *d'un besoin
utilisateur permanent* ! Qui vient de retours utilisateur des gens pour
qui je fais des sites (et que je confirme dans mon utilisation aussi).

C'est donc très exactement l'inverse de ce que tu dis là. C'est une
demande de fonctionnalité ergonomique, qui doit être simple et visible :
avoir un bouton très clair permettant de désactiver *ET réactiver* à
l'infini une Saisies, une Entrée de menu, une Noisette, etc (tous ces
plugins ont des interfaces sensiblement pareil au niveau ergonomique, et
le besoin utilisateur est exactement le même).

--
RastaPopoulos

cerdic · Mai 8, 2019, 4:25

Le 8 mai 2019 à 16:07 +0200, RastaPopoulos <rastapopoulos@spip.org>, a écrit :

Le 08/05/2019 à 15:55, Cerdic a écrit :
> Plus sérieusement ce fil me fait réagir, car une nouvelle fois je vois
> qu’au pretexte/en raison de vouloir avoir/faire une super API technique
> en dessous pour faire tout et son contraire, on va encore avoir une
> interface moisie car calquée sur l’API.

Je ne vois absolument pas à quel moment il a été question de ça.

Ben je sais pas, je dois entendre des voix, je suis un peu le jeune d’arc de SPIP, sûrement.

Mais bon quand je lis Maieul qui dit

Suis-je bete: on pourrait faire un mécanisme dans saisies pour avoir une option dans toutes les saisies.

Et toi qui lui réponds :

C’est le cas pour le champ « position » qui s’ajoute au form de config de 100% des saisies, quand bien même aucune valeur n’est enregistré dans « options » au final pour ce champ.

J’ai quand même un peu l’impression qu’il est question de ça…

Le fait est que ce fil porte sur un sujet, je réponds en plein dedans en disant ce qui semble le plus naturel et intuitif pour un utilisateur qui édite son formulaire puisque c’est ça le sujet et la question.
Mais non, j’ai rien compris à la discussion qui est infiniment plus globale et universelle que ce petit problème d’utilisateur de formidable, et d’ailleurs même, j’aurais du le deviner, il y a un morceau de cette discussion qui n’est pas dans le thread et que explique tout…

Enfin bref, faites comme vous voulez, je râlerai quand je l’utiliserai, toute la collaboration dans SPIP semble maintenant se limiter à ça.

Ciao

Cédric

rastapopoulos · Mai 8, 2019, 4:59

Le 08/05/2019 à 18:25, Cerdic a écrit :

Le fait est que ce fil porte sur un sujet, je réponds en plein dedans en
disant ce qui semble le plus naturel et intuitif pour un utilisateur qui
édite son formulaire puisque c’est ça le sujet et la question.

Il n'y a justement rien de spécialement évident à faire en sorte que
quand une personne *supprime* un champ, ce qui est un choix assez clair
et explicite, elle continue de voir des scories issues de ce champ dans
certaines pages ensuite ("mais… je l'avais supprimé ce champ").

Alors qu'un bouton "Désactiver/Réactiver" qui ne fait que dépublier sans
rien supprimer, alors là oui c'est logique de continuer à voir les
contenus déjà enregistré, de continuer à voir ce champ trainer dans
l'admin (et à pouvoir le remettre). Ça ne fait pas "magique",
comportement caché : c'est tout explicite. Et ça répond donc à mon avis
mieux et plus ergonomiquement, à la question de Maieul.

--
RastaPopoulos

JLuc · Mai 8, 2019, 6:45

Le 08/05/2019 à 18:59, RastaPopoulos a écrit :

Alors qu'un bouton "Désactiver/Réactiver" qui ne fait que dépublier sans
rien supprimer,

Justement, est ce pas là le terme qui convient : dépublier / republier ?

JL

alors là oui c'est logique de continuer à voir les
contenus déjà enregistré, de continuer à voir ce champ trainer dans
l'admin (et à pouvoir le remettre). Ça ne fait pas "magique",
comportement caché : c'est tout explicite. Et ça répond donc à mon avis
mieux et plus ergonomiquement, à la question de Maieul.

RealET · Mai 8, 2019, 7:27

JLuc a écrit le 08/05/2019 à 20:45 :

Le 08/05/2019 à 18:59, RastaPopoulos a écrit :

Alors qu'un bouton "Désactiver/Réactiver" qui ne fait que dépublier sans
rien supprimer,

Justement, est ce pas là le terme qui convient : dépublier / republier ?

Ça ressemblerait presque aux puces de statuts.
Avantage : on connait déjà ça dans SPIP.
Inconvénient : ça fait un clicodrome de plus (et je rejoins Cédric là-dessus)

Mais j'aime vraiment la proposition de Cédric.
Ça rejoint la notion de "Poubelle" existante dans SPIP.
Et ça ferait que le comportement serait plus cohérent avec le fonctionnement classique de SPIP.

--
RealET

maieul · Mai 8, 2019, 10:27

Le 08/05/2019 à 21:27, RealET a écrit :

JLuc a écrit le 08/05/2019 à 20:45 :

Le 08/05/2019 à 18:59, RastaPopoulos a écrit :

Alors qu'un bouton "Désactiver/Réactiver" qui ne fait que dépublier sans
rien supprimer,

Justement, est ce pas là le terme qui convient : dépublier / republier ?

Ça ressemblerait presque aux puces de statuts.
Avantage : on connait déjà ça dans SPIP.
Inconvénient : ça fait un clicodrome de plus (et je rejoins Cédric là-dessus)

par essence formidable est un clicodrome : il s'agit d'envisager un système souple de formulaire et configurable sans code. Donc je trouve que c'est lui faire un mauvais procés que de lui reproche ceci. Après on peut discuter de l'organisation des clics, de la structurartion des saisies etc...