Quand on valide un formulaire au clavier (touche entrée), c'est le 1er bouton submit présent qui est utilisé, mais il ne s'agit forcément du bouton de validation principal : ça peut être un bouton « revenir en arrière », « annuler », etc.
Ainsi on s’assure que ça soit le principal qui soit déclenché.
Il est ajouté via le _hidden du charger afin qu'il soit présent dans tous les formulaires qui déclarent des saisies, même ceux possédant leur propre html.
Pour un formulaire de configuration en déclaration automagique.
Si une saisie est de type "cle_secrete", s'assurer automatiquement de ne
pas perdre la valeur en base si jamais l'internaute ne la modifie pas.
ping @tcharlss
- il faut pouvoir avoir dans le contexte uniquement les saisies du
formulaire courant, et non pas l'ensemble des saisies lié au `meta_casier`
courant
- il faut avoir les saisies courantes (on ne peut pas s'en passer), car
le core se base sur le contexte pour savoir quoi mettre à jour en base
- il faut pouvoir définir les valeurs par défaut de l'ensemble des
saisies courantes, qu'elle soit de forme `toto` ou de forme `toto/truc`
Du coup :
1. Dans le cas des formulaires de config, on pre rempli les defaut avec
le résultat de lire_config
2. Puis on cherche les defaut pour remplir le contexte
C'est pas optimum (triple lecture du tableau) mais les formulaires de
config sont
1. Peu utilisés
2. Rarement énormes
"Optimisation : éviter d'appeler saisies_lister_par_etapes juste pour tester si on a des etapes"
Il y a des gens qui activent le mode multiétapes sur formidable sans pour autant mettre
de `fieldset`.
Résultat :
- le pipeline `verifier` croyait qu'on avait des étapes, et donc déléguait
les choses au pipeline `verifier_etapes`
- mais `verifier_etapes` lui ne voyait pas d'étape et ne vérifait rien.
Conclusion : on ne peut pas s'appuyer sur la simple option "activer le multi
étape" pour déterminer si effectivement on est en multiétape !
Toutefois, comme le calcul des étapes parcourts l'ensemble des saisies,
et est donc un peu long, on améliore `saisies_lister_par_etapes()` qui
peut recevoir un second paramètre `$check_only` qui se contente de
vérifier si effectivement on aurait ou pas des étapes, et renvoi true si
oui (mais donc pas le tableau complet d'étape).
- `saisies_lister_par_etapes()` ajoute une étape supplémentaire à la
fin, qui est le récapitulatif (sauf demande contraire dans les
options globales du formulaire)
l'ensemble des valeurs postées
- L'affichage de cette dernière étape est déportée dans le squelette `formulaires/inc-saisies-cvt-etapes-recapitulatif.html`, qui lui même appelle
`#VOIR_SAISIES`, en insérant au préalable une petite explication).
- Petite modification de `#VOIR_SAISIES` qui peut prendre une option
`voir_explications`.
- Option globales possible pour le tableau de saisies
`etapes_ignorer_recapitulatif`, si rempli, on ne fait pas de
récapitulatif
- Ajustement de divers css privé pour le récap des étapes
Excursus:
- On passe les boutons de retour arrière en `<button>`
- On passe aussi `|_T_ou_Typo` sur les boutons de validation
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).
automatiquement les saisies listées par étapes. En fallback, générer
cette liste si besoin, sur une idée de @rastapopolos.
Mais allons même plus loin : a priori on peut aussi chercher si
_saisies_par_etapes est présent dans l'environnement.
@rastapopoulos l'avais signalé par un banal `assests ?` sur IRC, mais je
n'avais pas compris qu'il signalé une coquille !
Du coup pour pas perdre les réglages ont est obligé de passer par un
script d'installation qui migre la meta. Mais pas grave, c'est toujours
bien d'avoir des scripts d'installation/de maj, car on ne sait pas de
quoi l'avenir sera fait.
d2b5c9eb38
pipeline `saisies_afficher_si_js_saisies_form` devient `saisies_afficher_si_saisies`.
On met une compat au cas où (même si j'ai des doutes que besoins).
A supprimer lors du passage en 4.0
C'est deja inclus... j'ai du louper un truc à un moment.
Merci @rastapopolous.
On release tout de même, dès fois que ce double --extra soit
problématique.
Pour le moment on ne va pas plus loins, car il faudrait que j'ai le temps de pencher plus en détails sur les fonctions de chargement de ces formulaires.
Mais cela va servir deja pour formidable (qui garde
`formulaire_editer_formulaire_charger()`).
Et enfin, indiquer les onglets en erreur avec un picto. Je prends celui qu'on a sous la main, mais ça serait mieux avec un plus léger. On verra plus tard.
Il s'agissait d'une scorie historique, lié au fait que le js était
dynamique.
Ce n'est plus le cas.
Or cette scorie pouvait poser problème dans le constructeur de saisies,
car le js était alors échappé.
On décide plutot de charger le js une bonne fois pour toute au
chargement de la page.
On adapte le code pour
1. Gérer le cas où l'on charge des formes en AJAX (type constructeur de
saisie)
2. Optimiser un peu le code
3. Avoir une nomenclatura plus cohérente
ping @tcharlss
* Fonctionne quelque soit la position du fieldset et son niveau d'imbrication
* Fonctionne avec l'option pour activer les étapes
* Incompatible avec l'option `pliable`
- utiliser un pipeline saisie_afficher_si_js_type qui dit le type de
test à générer. Exemple d'usage : la saisie evenements d'agenda ne doit
pas générer le même test selon qu'elle est configuré en mode radio ou en
mode checkbox ou en mode select
- déterminer automatiquement la fonction à utiliser
saisies_afficher_si_js_<type>, ce qui permettra de créer les propres
fonctions
- uniformisation des arguments des fonctions
- ca casse l'appel aux fonctions renommées / signature changées, mais
normalement est pas censé s'en servir publiquement
- jquery-ui.js : 508,86ko
- jsdyn-formulaires_dateur_jquery_dateur_js_14fce12d.js : 517,89 ko
Le fichier js dynamique est chargé via $.getScript depuis le fichier formulaire/dateur/inc-dateur.html qui inclut déjà lui-même jquery-ui !
On se retouve donc avec une double dose d'un jquery-ui (déjà pachidermique) à la moindre saisie date appelée. C'est clairement un problème.
Je m'interroge sur la nécessite de l'insertion des css et js via affichage_final. Sauf cas particulier qui m'échappe, je pense que cette fonction saisies_affichage_final n'a pas (plus) lieu d'être.
Je propose d'opter pour un chargement des éléments globaux via insert_head et insert_head_css (sans jquery-ui) et pour les cas particuliers, cela doit se gérer au niveau du squelette de la saisie (à l'instar de ce que fait déjà la saisie date qui fait un #INCLURE de inc-dateur.html).
En attendant des avis, on peut déjà rendre cette fonction surchargeable (désactivable).
Maïeul
tcharlss
nicod
RastaPopoulos
maieul@maieul.net