Les yaml de traiter disent parfois de passer l'env aux saisies (pour les saisies nom). Or, il y a comme env['id'] l'id du formulaire. Ce qui fait que ces sous-saisies avaient un id html égal à l'id du formulaire. Ce qu'on ne souhaite pas.
Cependant, on ne peut pas modifier directement le contexte du formulaire
de config des traitements, car plusieurs plugins utilise des tests sur
$contexte['id'] et pas sur $contexte['id_formulaire'].
Par conséquence, on se contente d'annuler ce contexte['id'] dans le html
avant de charger les saisies.

les yaml de traiter disent parfois de passer l'env aux saisies (pour les saisies nom). Or, il y avait comme env['id'] l'id du formulaire. Ce qui faisait que ces sous-saisies avaient un id html égal à l'id du formulaire. Ce qu'on ne souhaitait pas. Pour éviter cela, on précise de quel id on parle lorsqu'on charge le formulaire de config des traitements

conditionné par un afficher_si sont mis à null si la condition n'est pas
validée.

Ce qui veut dire concrètement que si on décoche une case d'un
traitement, toutes les infos sur ce traitement sont perdus. Or on peut
vouloir conserver les réglages d'un traitement sans pour autant
l'appliquer (si jamais on veut rebasculer).

Pour revenir à ce qui était le comportement historique de formidable
(basé sur un bug de saisies), on dit explicitement qu'on ne veut pas de
_request mis à null en cas d'afficher_si.

d'accusé de réception

  - mutualisation du code avec les autres saisies
  - conséquence : on peut l'appeler en précision le type de saisies pour
  selectionner la saisie. Donc pas limité au select, mais aussi radios
  ou checkbox

n'était pas une correction de trailing spaces, mais un
changement de casse ! J'ignore diable sur quelle touche j'ai cliqué pour
provoquer cela.
Mea culpa

- suppression d'un code mort sur test de valeur brute ou pas brute,
puisque par défaut renvoyait les deux, le test avait lieu en amont
- pour déterminer la valeur humaine, on se base désormais sur
saisie-vues/xxx, ce qui assure d'avoir une valeur humaine aussi lorsque
c'est prévu mais qu'il n'y a pas d'argument datas à la saisie,
typiquement pour les saisies de type evenements (plugin agenda)

[Salvatore] [source:_plugins_/formidable/trunk/lang/ formulaires_reponse] Export depuis http://trad.spip.net de la langue en

[Salvatore] [source:_plugins_/formidable/trunk/lang/ formulaire] Export depuis http://trad.spip.net de la langue en

[Salvatore] [source:_plugins_/formidable/trunk/lang/ formidable] Export depuis http://trad.spip.net de la langue en

il ne faut pas tester l'unicité du champ sur la réponse qu'on est en
train de modifier (Florence Henry)

refactorisation du code : une seule fonction pour trouver la réponse qui doit être modifié si on autorise la modification des réponses
Pour le moment appeller:
  - lors du chargement du formulaire
  - lors de l'enregistrement des réponses