WIP: issue_89

ping @rastapopoulos @nicod_

But

Cette PR propose de résoudre le pb #89 (closed), à savoir la gestion des afficher_si en multiétape.

Cela comprend 2 problèmes distinct :

1. permettre qu'un afficher_si à une étape dépende d'un saisie à une autre étape (idéalement antérieure, sinon ca va pas en terme de logique)
2. permettre qu'une étape soit conditionnée par un afficher_si (ce que j'appelle dans le code "avance rapide")

Tests

Pour tester il faut

• la branche
• pour formidable, la branche issue_89
• pour le core de SPIP :
  • master à jour
  • ou branche 3.2 à jour (attention, pas le tag 3.2.11, mais bien branche 3.2)

Je vous met en PJ 2 formulaires formidable qui m'ont servi, 1 pour chaque problème.

Ce qui casse

J'ai du casser 2 choses :

• le troisième argument de saisies_verifier() est désormais l'étape courante (avant : un tableau pouvant recevoir les erreurs spécifiques aux fichiers, mais personne ne s'en servait + on pourrait faire autrement pour gérer cela)
• les clés sur les regroupements par étape. Ce n'est plus x, y, z mais etape_x, etape_y, etape_z
  • techniquement j'aurais pu m'en passer, mais il fallait revoir le fonction de saisies_verifier_afficher_si, et sans doute casse du coup la signature de cette fonction pour passer des choses en plus en cas de recursion. Bref, une fonction sensible et pas simple :-). J'ai préféré pas prendre de risque.
  • de toute facon, c'est tjr plus sûr de ne pas avoir des clés numériques lorsque le numéro d'ordre est important
  • cela veut juste dire que si une personne surcharge inc-saisies-cvt-etapes.html, elle devra refaire sa surcharge (mais bon de toute facon... elle aurait du le faire pour profiter des autres points)

Ce qui va pas encore

le listing des étapes en haut doit être revue pour plusieurs raisons :

• accessibilité #95 (closed)
• style coté privé #91

Ce qu'il faut tester

Des cas réelle, avec des avances / retours en arrière (ca a bien marché sur un cas réel complexe chez moi)