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
structure du .yaml pour affecter une caté à une saisie et pour le rang
au sein de la catégorie.
````
categorie:
type: <cle_de_la_cate>#obligatoire
rang: <entier>#facultatif
````
+ on utilise une translittération pour s'assurer que selon l'ordre
alpha, Evenement se trouve bien avant rubrique (même si dans l'idéal il
faudrait utiliser la librairie intl de PHP...)
Lors de l'affichage par groupe, on trie selon ce rang (0 si pas défini),
et si égal, selon l'ordre alpha.
A noter que le tri est fait uniquement dans la fonction
saisies_lister_disponibles_par_categories(), catégories par catégories.
Le but étant d'avoir des listes les plus petites à trier, pour
optimiser. Si à l'usage le besoin se fait sentir de trier aussi dans
saisies_lister_disponibles, c'est trois ligne à déplacer.
On propose un tri, à discuter.
Et une variante qui l'appelle `saisies_lister_disponibles_sql_par_categories()` (juste pour le parallele avec `saisies_lister_disponibles_sql()`).
S'appuie sur une fonction `saisies_regrouper_disponibles_par_categories()` qui peut recevoir une tableau de saisies_listes en argument. Ca permet notamment de filtrer les saisies qu'on propose en amont.
- il y a des gens qui peuvent brancher leur pipeline dessus,
- peut être un jour aura-t-on plus de config, avec des afficher_si,
- profiter automatiquement des futures corrections sur les formulaires
construit automatiquement
En fait non : c'est deja prévu expressement dans la syntaxe... des fois je devrais relire ma propre documentation...
Merci Luc Mamin pour le signalement du bug...
This reverts commit 21a1f1bdc9.
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()`).
- ne plus mettre un display:none au chargement d'une saisie masquee
- mettre plutot une classe -afficher_si_masque_chargement en plus de
.afficher_si_masque (et donc si on demasque puis remasque, on aura
juster .afficher_si_masque)
- cette classe reprend le .offscreen de SPIP 3.3 :
- on ne met pas une class offscreen car on ne peut pas supposer qu'elle est chargée sur tout les sites
- de plus le .offscreen de la 3.2 ne résoud pas le problème (en tout cas pour la saisie carte)
- testé avec une saisie conditionnée de type carte, ca marche
