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

Modification d'une réponse depuis l'espace privé : le faire même si le formulaire n'autorise pas la modification par les utilisateurs de leurs propres réponses

tri des formulaires dans l'espace privé : par défaut par titre + garder l'ordre de tri d'une fois sur l'autre via la session

options pour ne pas envoyer d'email en cas de modif de réponse (par exemple: lorsqu'on modifie depuis l'espace privé)

Exemple d'emploi: un site qui gère des inscriptions à des évènements,
avec plusieurs dates possibles, pour modifier directement les infos sur la date de l'evenement retenue si la personne change d'avis.

lors de l'enregistrement d'une réponse, indiquer dans la chaine de traitement s'il s'agit d'une modif d'une reponse, pour que les les traitements ultérieures puissent, le cas échéant, avoir un comportement spécifique

Utiliser objet_modifier plutôt que sql_updateq pour générer une révision quand on modifie les traitements ou les saisies.
La restauration de révisions ne fonctionne pas pour autant, mais c'est un autre problème à régler.

Saisies champ : ne mettre l'entreé 'aucun' que si on est en radio. En effet, dans le cas des selects, c'est gérer directement par le select, dans les autres cas ce n'est pas pertinent

saisie champ : si forcer_type est n'est pas un tableau, ne pas essayer de le fusionner directement avec un tableau pour ajouter fieldset

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

saisie champ, l'option qui filtre par type conserve l'arborescence des fieldsets + lorsque deux champs sont homonymes, les conserve

retour sur r115838 : si un fieldset à un label, l'utiliser comme optgroup. On précise toutefois entre parenthese le nom, si jamais on a plusieurs fieldset avec le même label

si on autorise les pages publiques pour les formulaires, alors il faut mettre le lien pour les voir en ligne s'ils sont publiés

mettre dans l'aide memoire la liste des options possibles pour les champs y c'est pertinent. Utile notamment pour créer des afficher_si et autre

saisie champ : si un fieldset n'a pas de label, utiliser le nom de la saisie comme titre de optgroup

saisie champ : pouvoir voir les fieldset dans les fieldset. Par contre on rend pas cela comme dans des optgroup dans des optgroup, mais on aplatit les fieldset a partir du second niveau (normalement d'ailleurs on déconseille les fieldset dans les fieldset)