formulaire lorsqu'on l'appel dans un squelette.
Pour ce faire, on modifie la syntaxe de `#FORMULAIRE_FORMIDABLE`, qui ne
prend désormais plus que trois arguments
- id nunérique ou identifiant textuel du formulaire
- tableau de valeur par défaut
- tableau d'options
On assure la retrocompatibilité, car il y a beaucoup de gens pour qui le
troisième paramètre c'est l'id de réponse.

Attention, pour l'heure on ne peut pas le faire dans un contenu, car il
n'y pas de syntaxe SPIP pour passer des tableaux en options de formulaire.

saisies masquées par afficher_si. Lors de l'enregistrement des réponses
d'un formulaire, on cherche les saisies qui ont masquées et ont les mets
à `null`.

décide s'il affiche ou pas son message spécifique, en connaissant par
ailleur le message general.

Up de y.
Fix #58 (again !)

fix #59 : ne pas appliquer propre sur tous les retours de traitements, charge à chaque traitement de le faire

Puisque maintenant le javascript est à part, on peut mettre une case à
cocher pour demander d'afficher explicitement les messages de retour de chaque
traitement si jamais on a défini un message général.

cas de succès (formidable_subscribers). Ces scripts ne passent par
propre, contrairement aux vrais message_ok. Ils ne sont donc pas
échappés.

le message de retour n'est pas un array, donc le test n'avait pas lieu d'être. De toute facon, il y a un texte au niveau du squelette qui ne wrappe pas le message ok si vide

mais plus les changement de paragraphe.

On corriger en déportant propre directement dans le .php, message de
retour individuel par message de retour individuel.

ping @nicod_

Mieux : on collecte tous les messages de retour (le personnalisé + ceux des traitements), ce qui permet ensuite de les distinguer plus facilement avec des sauts de lignes.

Ticket #44 : afficher les messages de retour des traitements même s'il y a un message personnalisé, car ils peuvent contenir de informations importantes, ou être indispensables au fonctionnement même du formulaire s'ils contiennent du JS qui déclenche des actions. On fait au plus simple : Le message perso est placé au début, séparé par un saut de ligne.

charger() et pas à la fin de traiter(), sinon on ne peut pas accéder a
leurs valeurs dans le pipeline formulaire_traiter()

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

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.

retrouvent dans #GENERER_SAISIES.
Conséquence: lorsqu'on envoie le formulaire à nouveau après le post, les
champs sont préremplis. Ce qui ne correspond pas du tout au comportement
attendu "Le formulaire, à nouveau", et pas "le formulaire, à nouveau,
prérempli". Ceci pourrait expliquer du reste pourquoi des gens envoie
plusieurs fois le même formulaire.
On vide donc les _requests de saisies après l'application de l'ensemble
des traitements.

formulaire. Mais du coup, on avait plus _saisies en contexte, et par
conséquent formidable_definir_contexte_avec_reponse() ne pouvait pas
trouver correctement les saisies de type fichier.
On corrige en relisant les saisies directement passé à
$contexte['_formidable']

traitement. Utiliser cette vérif à chaque étape.

Pour le traitement enregistrer, tester l'unicité d'un champ si le champ
est dans l'étape courante.

Nouvelle fonctionnalité : on utilise toutes les modifs faites en amont sur Saisies. On peut donc maintenant configurer certaines options globales dans l'interface du constructeur. Pour cela on déclare au constructeur quelles options on accepte (c'est propre au contexte de Formidable).

Dans le lot, il y a donc la personnalisation du bouton final, et… le multi-étapes !

Pour cela, il a fallu faire un refactoring de la fonction verifier() de Formidable où tout était en dur… On l'a donc vidé de son contenu, afin que Formidable utilise enfin l'API CVT de Saisies avec la fonction saisies().

Au passsage, il y avait une vérification propre à un traitement (enregistrement) sur l'unicité : on en profite pour mettre en place un fonctionnement générique et extensible. Tout type de traitement peut désormais déclarer une fonction de vérification qui lui est propre avec traiter/montraitement_verifier(). Et si ça existe, ça sera utilisé.

Il reste un problème avec ce dernier point : pour le cas habituel ça continue de marcher pareil MAIS quand on active les étapes… Pour le moment j'ai fait le choix lorsqu'il y a étapes, de lancer ces vérifications propres aux traitements à la toute fin, quand on sait qu'on est à la dernière étape. Mais du coup ça ne va pas, car les erreurs ajoutées peuvent être sur des champs qui sont à d'autres étapes. Et CVT ne le sait pas, il reste sur la dernière étape. Donc ça montre "Vous avez X erreurs" en haut, mais on ne voit pas forcément le ou les champs précis en erreur s'ils sont ailleurs. Je ne sais pas encore comment résoudre ça…

Masquer les hidden, quelque soit la profondeur.