Afficher_si et multiétape #89

On relira au préalable https://contrib.spip.net/Fonctionnement-technique-de-la-verification-des#Cote-PHP

Pb 1 pouvoir avoir un afficher_si dépendant d'une saisie dans une étape précédente

Côté évaluation en JS

Pour les champs conditionnant classique
- Dans la fonction saisies_afficher_si_js_defaut() > $saisie_form devrait être l'ensemble des saisies, par étape
- Il faut regarder si la saisie conditionnante est dans une autre étape -> si oui on fait directement l'évaluation PHP, si non on met l'insert JS
Pour les champs fichiers ``saisies_afficher_si_js_defaut()` > bah du coup il faudrait là avoir les saisies, mais par cohérent elle seront listés par étapes, et donc il faudra adapter zun peu le code...

Côté évaluation en PHP

Idem. Les valeurs des étapes précédentes étant disponible via _request, ca devrait passer crême

PB 2 Pouvoir conditionner une étape par afficher_si

Ca c'est relativement facile, suffit juste d'appeler la fonction php saisies_evaluer_afficher_si() avant de balancer l'étape.

On relira au préalable https://contrib.spip.net/Fonctionnement-technique-de-la-verification-des#Cote-PHP ## Pb 1 pouvoir avoir un afficher_si dépendant d'une saisie dans une étape précédente ### Côté évaluation en JS - Pour les champs conditionnant classique - Dans la fonction `saisies_afficher_si_js_defaut()` > `$saisie_form` devrait être l'ensemble des saisies, par étape - Il faut regarder si la saisie conditionnante est dans une autre étape -> si oui on fait directement l'évaluation PHP, si non on met l'insert JS - Pour les champs fichiers ``saisies_afficher_si_js_defaut()` > bah du coup il faudrait là avoir les saisies, mais par cohérent elle seront listés par étapes, et donc il faudra adapter zun peu le code... ## Côté évaluation en PHP Idem. Les valeurs des étapes précédentes étant disponible via `_request`, ca devrait passer crême ## PB 2 Pouvoir conditionner une étape par afficher_si Ca c'est relativement facile, suffit juste d'appeler la fonction php `saisies_evaluer_afficher_si()` avant de balancer l'étape.

Ca c'est relativement facile

Ça dépend :p

On ne "balance pas l'étape", leur nombre est déclarée au départ dans le charger. Donc si ya des conditions pas remplies, faut pas déclarer la même chose.
https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/saisies_pipelines.php#L197

Ou bien faut laisser le même nombre (histoire que l'étape 4 reste toujours l'étape 4) mais faut arriver à ce que ça passe direct à la 5 si ceci-cela, sauf que ça dans l'API multi-étapes du core je sais pas du tout si on a la main dessus.

> Ca c'est relativement facile Ça dépend :p On ne "balance pas l'étape", leur nombre est déclarée au départ dans le charger. Donc si ya des conditions pas remplies, faut pas déclarer la même chose. https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/saisies_pipelines.php#L197 Ou bien faut laisser le même nombre (histoire que l'étape 4 reste *toujours* l'étape 4) mais faut arriver à ce que ça passe direct à la 5 si ceci-cela, sauf que ça dans l'API multi-étapes *du core* je sais pas du tout si on a la main dessus.

Je dirais l'option 2. Et si côté formulaire on peut dire "aller à une étape" en indiquant un numéro d'étape (cf message de cerdic ici https://core.spip.net/issues/4699), bah j'imagine que du coup il doit y avoir une fonction qui permet juste de trouver l'étape à utiliser. Au pire du pire, on fait un `set_request('aller_a_etape', n+1); si jamais on saute l'étape n. Enfin c'est ce que je dirais spontanément sans fouiller le core...

Il s'agit pas de savoir calculer la bonne étape où aller. Ce que je dis c'est qu'on a pas forcément la main dans le core (par un pipeline à priori si ça existait) sur cette décision de où aller, de quoi afficher ensuite.

Concrètement l'étape demandée explicitement (si ça existe) est récupérée avant tout pipeline :
https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/cvt_multietapes.php#L224

Alors que la méthode ancienne _retour_etape_N est elle appelée après le pipeline :
https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/cvt_multietapes.php#L253

Il faudrait donc :

corriger le core, pour déplacer "aller_a_etape" juste avant l'autre, après le pipeline
dans le pipeline, qu'on utilise déjà, il suffit donc à priori de faire un set_request('aller_a_etape', ) avec le bon numéro, et paf, ça sautera comme il faut !

Il s'agit pas de savoir calculer la bonne étape où aller. Ce que je dis c'est qu'on a pas forcément la main *dans le core* (par un pipeline à priori si ça existait) sur cette décision de où aller, de quoi afficher ensuite. Concrètement l'étape demandée explicitement (si ça existe) est récupérée avant tout pipeline : https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/cvt_multietapes.php#L224 Alors que la méthode ancienne `_retour_etape_N` est elle appelée après le pipeline : https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/cvt_multietapes.php#L253 Il faudrait donc : 1) corriger le core, pour déplacer "aller_a_etape" juste avant l'autre, après le pipeline 2) dans le pipeline, qu'on utilise déjà, il suffit donc à priori de faire un set_request('aller_a_etape', ) avec le bon numéro, et paf, ça sautera comme il faut !

Si je reprend le problème 1, a savoir du afficher_si cross etape, l'un des soucis que j'ai c'est qu'à chaque étape, je n'ai que la liste des saisies courantes.

        #SET{saisies, #ENV{_saisies}}
        [(#ENV{_etape}|oui)
            #SET{saisies, #GET{etapes}|table_valeur{#ENV{_etape}/saisies}}
        ]
        #GENERER_SAISIES{#GET{saisies}}

Alors qu'ilfaut l'ensemble des carac des saisies (notamment pour distinguer saisies fichiers des autres) pour pouvoir generer un afficher_si.

Je vois pas comment on peut couper à modifier la syntaxe de #GENERER_SAISIES.

Soit #GENERER_SAISIES{#ENV{saisies},<etape>}
Soit #GENERER_SAISIES{<saisies_etape_courante>,<saisies_toutes>}

Si je reprend le problème 1, a savoir du afficher_si cross etape, l'un des soucis que j'ai c'est qu'à chaque étape, je n'ai que la liste des saisies courantes. #SET{saisies, #ENV{_saisies}} [(#ENV{_etape}|oui) #SET{saisies, #GET{etapes}|table_valeur{#ENV{_etape}/saisies}} ] #GENERER_SAISIES{#GET{saisies}} Alors qu'ilfaut l'ensemble des carac des saisies (notamment pour distinguer saisies fichiers des autres) pour pouvoir generer un afficher_si. Je vois pas comment on peut couper à modifier la syntaxe de <code>#GENERER_SAISIES</code>. - Soit `#GENERER_SAISIES{#ENV{saisies},<etape>}` - Soit `#GENERER_SAISIES{<saisies_etape_courante>,<saisies_toutes>}`

La première syntaxe a plutot ma préférence.

Je dirais donc plutôt le 1, mais il n'y a pas à prévoir d'arg en plus : #GENERER_SAISIES{#ENV{saisies},etape=#ENV{_etape}} (aucun #GET donc)

Et c'est dans inc/generer_saisies qu'il faudra refaire un lister_par_etapes au début, pour n'afficher que les saisies de l'étape. Et par contre dans le #ENV envoyé à generer_html() la clé "saisies" aura donc bien tout. Par contre ya que pour le cas #ENV{_env} que là ça n'y serait pas, mais je ne sais plus pour quels cas c'est utilisé…

Ce qui m'embête aussi c'est de lancer plusieurs fois lister_par_etapes (là déjà 2 fois actuellement, et 3 fois avec cette modif), ça refait les mêmes choses à chaque fois.

Je dirais donc plutôt le 1, mais il n'y a pas à prévoir d'arg en plus : `#GENERER_SAISIES{#ENV{saisies},etape=#ENV{_etape}}` (aucun #GET donc) Et c'est dans inc/generer_saisies qu'il faudra refaire un lister_par_etapes au début, pour n'afficher que les saisies de l'étape. Et par contre dans le #ENV envoyé à generer_html() la clé "saisies" aura donc bien tout. Par contre ya que pour le cas `#ENV{_env}` que là ça n'y serait pas, mais je ne sais plus pour quels cas c'est utilisé… Ce qui m'embête aussi c'est de lancer plusieurs fois lister_par_etapes (là déjà 2 fois actuellement, et 3 fois avec cette modif), ça refait les mêmes choses à chaque fois.

#GENERER_SAISIES{#ENV{saisies},etape=#ENV{_etape}} (aucun #GET donc)

on peut avoir des arguments nommés sur des balises ? en dehors de #SAISIE s'entend. (et je ne sais pas d'où tu sorts de GET putatif, mais peu importe puisqu'il y est pas :)

Par contre ya que pour le cas #ENV{_env} que là ça n'y serait pas, mais je ne sais plus pour quels cas c'est utilisé…

Dans

inclure/voir_saisies.html (donc pas concerné à priori)
inclure/generer_saisies.html mais je ne sais pas quand et où ce _env est censé arrivé jusqu'à là (mais si c'est l'environnement, il doit bien contenur #ENV{saisies} aussi non ? donc avec toutes les saisies
formulaires/inc-generer_saisies_configurables.html, mais pareil je ne sais pas d'où cela vient :)

Ce qui m'embête aussi c'est de lancer plusieurs fois lister_par_etapes (là déjà 2 fois actuellement, et 3 fois avec cette modif), ça refait les mêmes choses à chaque fois.

Là comme cela je vois trois pistes

Est-ce qu'on a vraiment besoin de passer les saisies listées par etapes au .html du formulaire ?
Peut être un static, mais bon ca voudrait dire serializé les saisies pour distinguer selon ce qu'on recoit, donc pas sur qu'on y gagner du temps
Je me demande si on ne pourrait pas optimiser la fonction en parcourant une seule fois le tableau de saisies, et on ne renvoie saisies_etapes que s'il a au moins 2 entrées.

> `#GENERER_SAISIES{#ENV{saisies},etape=#ENV{_etape}} (aucun #GET donc)` on peut avoir des arguments nommés sur des balises ? en dehors de <code>#SAISIE</code> s'entend. (et je ne sais pas d'où tu sorts de GET putatif, mais peu importe puisqu'il y est pas :) > Par contre ya que pour le cas `#ENV{_env}` que là ça n'y serait pas, mais je ne sais plus pour quels cas c'est utilisé… Dans - `inclure/voir_saisies.html` (donc pas concerné à priori) - `inclure/generer_saisies.html` mais je ne sais pas quand et où ce `_env` est censé arrivé jusqu'à là (mais si c'est l'environnement, il doit bien contenur `#ENV{saisies}` aussi non ? donc avec toutes les saisies - `formulaires/inc-generer_saisies_configurables.html`, mais pareil je ne sais pas d'où cela vient :) > Ce qui m'embête aussi c'est de lancer plusieurs fois lister_par_etapes (là déjà 2 fois actuellement, et 3 fois avec cette modif), ça refait les mêmes choses à chaque fois. Là comme cela je vois trois pistes 1. Est-ce qu'on a vraiment besoin de passer les saisies listées par etapes au .html du formulaire ? 2. Peut être un static, mais bon ca voudrait dire serializé les saisies pour distinguer selon ce qu'on recoit, donc pas sur qu'on y gagner du temps 3. Je me demande si on ne pourrait pas optimiser la fonction en parcourant une seule fois le tableau de saisies, et on ne renvoie saisies_etapes que s'il a au moins 2 entrées.

En fait pour la partie "Afficher si entre saisie d'étape différente", il y a vraiment que ce point à résoudre, vu que toutes les infos sur les étapes précédentes sont stockés en hidden à chaque étape, et que, depuis la réécriture d'afficher_si JS, peut importe si c'est en hidden, radio, input ou autre.

Les balises #SAISIE et #GENERER_SAISIES ne sont que des redirections vers INCLURE depuis le début donc oui on peut avoir des arguments nommés. C'est même marqué dans le code :)
https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/balise/generer_saisies.php#L21

Je disais aucun #GET pas par rapport à toi, mais c'est bien des #GET changé en amont utilisé dans le code actuel. Donc là on ne modifierait rien en amont, mais uniquement en aval.

Pour _env je ne me demandais pas tant où c'est utilisé, mais où c'est rempli pour quels cas. Et c'est donc dans saisies_afficher
https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/inc/saisies_afficher.php#L149

Mais de ce que je me souviens c'est pour l'affichage des sous saisies quand ya des conteneurs comme fieldset. Enfin bon à tester voir si ça pète rien juste avec ce que je disais plus haut…

Pour ce qui est des appels multiples : oui on a besoin de passer les saisies listées par étape car c'est utilisé pour le chemin notamment. Ça utilise des infos de chaque fieldset racine trouvés, dans tous les cas faut avoir les saisies complètes (et là ça utilise que le label/legend, mais on peut très bien imaginer qu'une personne surcharge ce chemin pour mettre le titre + l'explication ou encore le nombre de sous-saisies à remplir pour chacune des étapes genre "Étape 1 (45 champs)", etc : on doit laisser les infos complètes).

Je pense pas qu'on puisse fait un static, ya pas d'identifiant unique pour stocker et puis ça peut changer suivant des pipelines etc. Par contre une fois découpé en étapes, on pourrait le stocker dans une clé dédiée, càd à la fois envoyer _saisies et _saisies_par_etapes (seulement si existantes) et du coup l'avoir déjà sous la main, et on le passe à #GENERER_SAISIES aussi. Et dans le squelette de generer_saisies : si ya "etape" demandé, on utilise saisies_par_etape si déjà présent dans l'environnement, sinon seulement en fallback à tout hasard on le reconstruit avec saisies.

#SET{saisies, #ENV{saisies}}

[(#ENV{etape}|oui)
	#SET{saisies_par_etapes, #ENV{saisies_par_etapes, #ENV{saisies}|saisies_lister_par_etapes}}
    
    #SET{saisies, #GET{saisies_par_etapes/#ENV{etape}/saisies}}
]


<BOUCLE_contenu(POUR){tableau #GET{saisies}}>

Les balises #SAISIE et #GENERER_SAISIES ne sont que des redirections vers INCLURE depuis le début donc oui on peut avoir des arguments nommés. C'est même marqué dans le code :) https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/balise/generer_saisies.php#L21 Je disais aucun #GET pas par rapport à toi, mais c'est bien des #GET changé en amont utilisé *dans le code actuel*. Donc là on ne modifierait rien en amont, mais uniquement en aval. Pour `_env` je ne me demandais pas tant où c'est utilisé, mais où c'est *rempli* pour quels cas. Et c'est donc dans saisies_afficher https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/inc/saisies_afficher.php#L149 Mais de ce que je me souviens c'est pour l'affichage des sous saisies quand ya des conteneurs comme fieldset. Enfin bon à tester voir si ça pète rien juste avec ce que je disais plus haut… Pour ce qui est des appels multiples : oui on a besoin de passer les saisies listées par étape car c'est utilisé pour le chemin notamment. Ça utilise des infos de chaque fieldset racine trouvés, dans tous les cas faut avoir les saisies complètes (et là ça utilise que le label/legend, mais on peut très bien imaginer qu'une personne surcharge ce chemin pour mettre le titre + l'explication ou encore le nombre de sous-saisies à remplir pour chacune des étapes genre "Étape 1 (45 champs)", etc : on doit laisser les infos complètes). Je pense pas qu'on puisse fait un static, ya pas d'identifiant unique pour stocker et puis ça peut changer suivant des pipelines etc. Par contre une fois découpé en étapes, on pourrait le stocker dans une clé dédiée, càd à la fois envoyer `_saisies` et `_saisies_par_etapes` (seulement si existantes) et du coup l'avoir déjà sous la main, et on le passe à #GENERER_SAISIES aussi. Et dans le squelette de generer_saisies : si ya "etape" demandé, on utilise `saisies_par_etape` si déjà présent dans l'environnement, sinon seulement en fallback à tout hasard on le reconstruit avec `saisies`. ``` html #SET{saisies, #ENV{saisies}} [(#ENV{etape}|oui) #SET{saisies_par_etapes, #ENV{saisies_par_etapes, #ENV{saisies}|saisies_lister_par_etapes}} #SET{saisies, #GET{saisies_par_etapes/#ENV{etape}/saisies}} ] <BOUCLE_contenu(POUR){tableau #GET{saisies}}> ```

Ca me parait cohérent tout ca.

Mais en lisant le code de generer_saisies, je vois "#INCLURE{fond=inclure/generer_saisies,env,saisies=#TABLEAU_DE_SAISIES}"

Du coup le env est deja transmis, donc a priori pas besoin de modifier la syntaxe de #GENERERER_SAISIES, faut juste modifier son code. Enfin à tester concrètement.

Par contre je reviens sur ce que j'ai dit concerant le code JS, il faudrat bien generer un code JS différents (juste false ou true) pour les saisies des étapes précédentes, car les valeurs sont stockés de manière chiffrés dans les hidden.

Ca me parait cohérent tout ca. Mais en lisant le code de generer_saisies, je vois "`#INCLURE{fond=inclure/generer_saisies,env,saisies=#TABLEAU_DE_SAISIES}`" Du coup le env est deja transmis, donc a priori pas besoin de modifier la syntaxe de `#GENERERER_SAISIES`, faut juste modifier son code. Enfin à tester concrètement. Par contre je reviens sur ce que j'ai dit concerant le code JS, il faudrat bien generer un code JS différents (juste false ou true) pour les saisies des étapes précédentes, car les valeurs sont stockés de manière chiffrés dans les hidden.

J'ai testé, pour moi ça a l'air de bien fonctionner, tu penses qu'on peut merger ainsi que la branche saisies_issue89 de formidable ?

j'aimerais mieux éviter pour l'instant pour deux raisons :

ca s'appuie sur des fonctionnalités du core qui ne sont pas encore releasé. Et donc je préfererais éviter de releaser un truc potentiellement pas utilisable pour les gens qui n'utilisent pas git :)
j'ai legerement changé un point d'implémentation, qui attend du coup un merge dans le core spip/spip#165/commits

Mais donc dès que la 3.2.12 sera sortie, on pourra merger et releaser

j'aimerais mieux éviter pour l'instant pour deux raisons : - ca s'appuie sur des fonctionnalités du core qui ne sont pas encore releasé. Et donc je préfererais éviter de releaser un truc potentiellement pas utilisable pour les gens qui n'utilisent pas git :) - j'ai legerement changé un point d'implémentation, qui attend du coup un merge dans le core https://git.spip.net/spip/spip/pulls/165/commits Mais donc dès que la 3.2.12 sera sortie, on pourra merger et releaser

Ok, merci du retour.

Labels Milestones

Afficher_si et multiétape #89

Pb 1 pouvoir avoir un afficher_si dépendant d'une saisie dans une étape précédente

Côté évaluation en JS

Côté évaluation en PHP

PB 2 Pouvoir conditionner une étape par afficher_si