spip-contrib-extensions
/
saisies
99
2
Fork 0
Code Issues 40 Pull Requests 6 Releases Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1258 Commits
13 Branches
397 Tags
117 MiB
Tree: 80629ac46e
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '80629ac46e'
${ noResults }
saisies/formulaires/inc-saisies-cvt-etapes-defa...

26 lines
1.1 KiB
Raw Normal View History Unescape

Pb #95. Pouvoir avoir des variantes pour la présentation des étapes, chaque variante étant dans un squelette spécifique. Pour l'instant on a - 'defaut', qui est ce qui est proposé actuellement - 'courante', pour n'afficher que l'étape courante + le nb total d'étapes. == Mode defaut - Ne pas renvoyer les étapes passées masquées par afficher_si - Passage des boutons de `<input>` à `<button name="aller_a_etape">` == Mode courante Je reprend le code de @nicod_, aux adaptations suivantes : - utiliser les mêmes conventions de nommage css que pour le modèle `defaut` - utiliser une chaine de langue à laquelle on passe : - le numéro de l'étape courante (déjà encapsulé) - le nbre totale d'étape (déjà encapsulé) - le nom de l'étape courante - on peut ainsi suivre plus facilement les conventions par langue; Concernant la gestion des `afficher_si` : - le numéro de l'étape courante est calculé côté squelette en tenant compte des étapes passées qui sont masquées (vu que normalement une saisie dans l'étape actuellement ne peut pas changer le masquage des étapes masquées) - le nbr totale d'étape - n'inclut pas les étapes passées masquées par afficher_si - inclut toutes les étapes futures - est ajusté en JS au chargement + à chaque modification d'un champ en fonction des afficher_si
2 years ago
#SET{afficher_si_masquees,#VAL{'get'}|saisies_afficher_si_liste_masquees}
<B_etapes>
<nav class="formulaire_spip__etapes etapes" aria-label="<:saisies:etapes_formulaire:>">
<ol class="etapes__items">
<BOUCLE_etapes(DATA){source table, #ENV{etapes}}>
Affichage des étapes : si on sait qu'une étape future n'est conditionnée par AUCUN champ de l'étape courante, alors on effectue directement le tests d'afficher_si côté PHP, et, selon le résultat, on indique ou pas l'étape dans la liste.
2 years ago
#SET{etape,#CLE|replace{etape_,''}}
#SET{afficher_si,#VALEUR{options/afficher_si}|saisies_afficher_si_js{#ENV{etapes}}}
#SET{afficher,non}
Bugfix sur le listing des étapes : pour les étapes qui ne vérifient pas les afficher_si au hit current, ne masquer que les étapes passées
2 years ago
[(#VALEUR|in_any{#GET{afficher_si_masquees}}|non|ou{#ENV{_etape}|<{#GET{etape}}})
Affichage des étapes : si on sait qu'une étape future n'est conditionnée par AUCUN champ de l'étape courante, alors on effectue directement le tests d'afficher_si côté PHP, et, selon le résultat, on indique ou pas l'étape dans la liste.
2 years ago
#SET{afficher,oui}
[(#GET{afficher_si}|saisies_afficher_si_js_est_statique|oui)
#SET{afficher,#GET{afficher_si}|saisies_evaluer_afficher_si}
]
]
[(#GET{afficher}|oui)
<li [data-afficher_si="(#GET{afficher_si})"] class="etapes__item"[(#ENV{_etape}|=={#GET{etape}}|oui) aria-current="step"]>
Fix #96 - `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
2 years ago
[(#ENV{_etape}|>{#GET{etape}}|oui)<button type="submit" class="submit" name="aller_a_etape" value="#GET{etape}">#VALEUR{options/label}</button>]
Pb #95. Pouvoir avoir des variantes pour la présentation des étapes, chaque variante étant dans un squelette spécifique. Pour l'instant on a - 'defaut', qui est ce qui est proposé actuellement - 'courante', pour n'afficher que l'étape courante + le nb total d'étapes. == Mode defaut - Ne pas renvoyer les étapes passées masquées par afficher_si - Passage des boutons de `<input>` à `<button name="aller_a_etape">` == Mode courante Je reprend le code de @nicod_, aux adaptations suivantes : - utiliser les mêmes conventions de nommage css que pour le modèle `defaut` - utiliser une chaine de langue à laquelle on passe : - le numéro de l'étape courante (déjà encapsulé) - le nbre totale d'étape (déjà encapsulé) - le nom de l'étape courante - on peut ainsi suivre plus facilement les conventions par langue; Concernant la gestion des `afficher_si` : - le numéro de l'étape courante est calculé côté squelette en tenant compte des étapes passées qui sont masquées (vu que normalement une saisie dans l'étape actuellement ne peut pas changer le masquage des étapes masquées) - le nbr totale d'étape - n'inclut pas les étapes passées masquées par afficher_si - inclut toutes les étapes futures - est ajusté en JS au chargement + à chaque modification d'un champ en fonction des afficher_si
2 years ago
[(#ENV{_etape}|=={#GET{etape}}|oui)<em>#VALEUR{options/label}</em>]
[(#ENV{_etape}|<{#GET{etape}}|oui)<span>#VALEUR{options/label}</span>]
</li>
]
</BOUCLE_etapes>
</ol>
</nav>
</B_etapes>