les valeurs n'ont pas dans _request() mais dans l'enregistrement d'une
réponse. On peut donc facilement utiliser le raccourci @@ pour afficher
une présentation particulière d'une réponse donnée (cas d'usage : un
plugin perso pour une application métier).

Du coup on fait appel à cette fonction pour affiche_resume_reponse() en
gardant la compatibilité ascendante de ce qui est passé au pipeline
homonyme (dont je doute que qui que ce soit l'utilise, mais c'est une
autre affaire).

l'espace privé affiche pour un formulaire donnée le formulaire, sans passer d'identifiant explicite de réponse précédente. Du coup l'option d'identification par id de réponse plantait (erreur sql). On corrige cela (Florence Henry, contrib)

méthode d'identification de la réponse à éditer : par passage explicite
de l'identifiant, sans tenir compte ni du cookie, ni de l'id_auteur.

ne pas proposer de ne pas stocker l'id_auteur si jamais on utilise l'id_auteur pour identifier une réponse et qu'en plus on a besoin d'identifer une réponse

en r112879 je disais "compatibilité assuré pour les gens qui auraient modifié les variables globales". C'était faux. Maintenant c'est vrai

Etape 5 : avoir une fonction qui trouve la réponse d'une personne à un formulaire tenant compte du choix principal d'identification des réponses

dire supprimer l'id_auteur

éviter de mettre une définition  dans un options, lorsque la valeur n'est utilisé que dans une fonction. Autant définir dans ce cas dans la fonction

- code plus clair en évitant de créer des variables juste pour inverser le résultat d'un test, et pour recopier la valeur d'une variable sans la modifier après (!)
- plus de variables globales pour modifier un réglage (qui de toute facon
aurait du passer plutot par un pipeline dédiée)
- limiter les cas d'appel a eval()

Compatibilité assuré pour les quelques personnes qui auraient modifiés
ces variables globales (mais qui?)

- 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)

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

On mutualise le code (ce qui en plus rend plus lisible la fonction de
traitement des emails)

Changement de méthode d'obtention de l'id_formulaire pour calculé l'id_auteur scrambled. Avant il était toujours vide et c'était seulement l'id_auteur et le mot de passe qui servait au scramble.

Trier les traitement par ordre alpha, on aura ainsi toujours le meme ordre, et non pas quelque chose qui change en fonction du path et des plugins actifs

pouvoir aussi exporter les stats sur choix_couleurs (remarque : il serait bon de prévoir un mécanisme générique en fonction de la description de la saisie

analyse des données : prendre en compte le fait que désormais les saisies de type sélection peuvent avoir des sous-saisies (optgroup)

pas garder de traces des utilisateurs ayant répondu (tout en gardant
la possibilité d'avoir des réponses uniques, modifiables

* traitement de l'anonymisation. Elle permet de créer des formulaires dont les réponses sont anonymes (pas d'adresse IP, pas de nom de cookie, pas de login)
* export de l'analyse des données en en CSV depuis l'Espace Privé

On décore d'un graphisme les analyses des réponses de formulaire en mettant des barres de progression et des pourcentages. Le code provient du module de sondage qu'on va intégrer directement dans formidable en créant un nouveau type de retour.

filtre singulier ou pluriel sur le nombre de réponses sur la page d'analyse.

Notices PHP lors de l'utilisation de Formidable. Ajout d'un filtre pour désérialiser si possible sans générer d'erreur