API :
- pouvoir avoir plusieurs verif (tableau) ;
- on annonce toutes les erreurs de toutes les vérif dans l'ordre, séparées par un retour chariot;
- possibilité de garder l'ancien appel en donnant une seule verification ;
(exemple sur la saisie calcul, qui permet de combiner calcul et
afficher_si). Il faut donc qu'elle passe systématiquement en dernier
après le vidage des afficher_si.
On corrige donc un bug apparu récement quant au vidage des afficher_si.
Note :
La vérification des valeurs acceptables est là pour s'assurer que les
personnes n'ont pas truandé le HTML.
Du coup cela veut dire que si jamais on a une valeur innacceptable,
c'est que la personne a truandé, et donc on s'en fiche de lui renvoyer
un formulaire avec des afficher_si vide.
Etape a. Tester les futures étapes, et tant que condition d'afficher_si
pas rempli, avancer à l'étape suivante.
Attention cela nécessite des ajustements du core pas encore
officiellement releasés, mais présent dans :
- SPIP 3.3/4
- ou spip 3.2.12
Le fichier du core concerné est `inc/cvt_multietape.php`.
Cela nécessite également une reéécriture du retour de la fonction
`saisies_lister_par_etapes()`, qui au lieu de renvoyer
```
array(
x => array(...),
y => array(...),
z => array(...),
)
```
renvoie désormais
```
array(
etape_x => array(...),
etape_y => array(...),
etape_z => array(...),
)
```
En dehors de saisies et formidable, personne n'utilise encore pour
l'instant cette fonction, donc on peut se permettre la rupture.
But : `saisies_verifier_afficher_si()` supprime du tableau de saisies les étapes masquées par
afficher_si, et utilise par ailleurs des `array_merge()` sur le tableau de saisies pour gérer la récursion. Si on garde des clés strictement numériques, alors, en
supposant que l'étape y est masquée par afficher si, on obtient un
tableau de saisies de type
```
array(
x => array(...),
y => array(...),
)
```
et non pas, comme on le désirerait
```
array(
x => array(...),
z => array(...),
)
```
En préfixant les les clés, on obtient bien
```
array(
etape_x => array(...),
etape_z => array(...),
)
```
Ce qui permet de ne pas tenter à l'étape y d'appliquer les vérifications de l'étape z.
toutes les saisies, de toutes les étapes, pour que
saisies_verifier_afficher_si sache sur la base de quoi faire ses tests.
On modifie la signature
1. `$formulaire` inchangé
2. `$saisies_empty_string` inchangé
3. `&$erreurs_fichiers` remplacé par `$etape`. On se permet de ne plus
supporter cette variable et de changer la signature car il y avait deux
uses cases sur tout git.spip.net
a. Formidable, mais ce n'est plus le cas depuis un bout de temps, et
visiblement on s'en porte pas plus mal
b. Les demo dans CVT-upload, et le seuls usage c'est de nettoyer
`$_FILES` des fichiers en erreur au sens de ne repondant pas à des
critères dans `verifier_fichier()`. Pas franchement très utile (et au
pire on se débrouillera autrement si le besoin se fait sentir, genre
un setter/getter).
saisies_verifier(), à savoir saisies_verifier_valeurs_acceptables() et
saisies_verifier_obligatoire().
1. Prendre systématiquement les saisies aplaties et triées par nom.
2. Le filtrage des afficher_si éventuels se fait en amont.
On en profite pour créer une fonction saisies_est_fichier() pour dire si
la saisie renvoie ou doit renvoyer quelque chose dans `$_FILES`.
Merci Luc Mamin pour le signalement
Quelques refactoring ou mise en fonction en passant en passant :
- Une fonction `saisies_request_from_FILES($champs)` pour trouver le sous tableau de `$_FILES`.
- Note : pour l'heure je copie tel quel, ca ne gère pas les names
tabulaire avec clé non numérique. Mais bon... qui utiliserait cela pour des fichiers ? C'est tellement galère à gérer après...
- `saisies_get_valeur_saisie($saisie)`, s'appuyant sur la précédente permettant de trouver la
valeur d'une saisie qu'elle sont standard ou fichiers.
Maïeul
RastaPopoulos