Bonjour,
Je gère le site internet d’un festival qui fait appel à de nombreux bénévoles. À partir d’une liste des postes et des créneaux horaires disponibles pour chacun des postes, les bénévoles s’inscrivent via un formulaire formidable présent sur une page générique.
Cette page est appelée par une url qui envoie au formulaire le nom du poste (postname) et le créneau horaire (time) choisis :
ex : ruedesarts.net/?page=inscription&postname=Buvette église Vendredi&time=16h-18h
postname et time sont récupérés/traités par le formulaire sous forme de champ cachés, le bénévole se contentant de renseigner son nom, son numéro de portable etc…
Ça fonctionne bien. Là où je coince c’est que je souhaiterais faire apparaitre sous le formulaire d’inscription la liste des personnes déjà inscrites à ce poste et à cet horaire
Sauf que tu as 2 critères, donc dans cette boucle il ne faut retenir que les horaires voulus. Ça pourrait être une nouvelle boucle imbriquée, mais aussi plus simplement avec juste un test dans la boucle :
[(#VOIR_REPONSE{hidden_2}|=={#ENV{time}}|oui)
afficher ce que tu veux ici
]
Tel quel, cela ne fonctionne pas. J’ai tenté d’adapter le code en essayant
[(#VOIR_REPONSE{hidden_2,valeur_uniquement}|=={#ENV{time}}|oui)
afficher ce que tu veux ici
]
Mais ça n’est pas mieux.
Tout se passe comme si le test d’égalité entre hidden_2 et env{time} ne fonctionnait pas bien que, a priori, hidden_2, valeur_uniquement et #ENV(time) contiennent la même chose
Il n’y a pas de <pre> dans ton code donc on ne peut pas savoir ce qui est produit, on voit seulement ce qui s’affiche, mais SPIP ne teste pas l’affichage, SPIP teste ce qui est produit et c’est ce test qu’on veut débuguer, donc ça aide pas là comme ça.
Donc STP ajoute le pre comme indiqué précédemment.
Et aussi met quelque chose autour, par exemple des " comme ça on verra s’il y a pas un problème d’espace en trop dans une des valeurs.
[Résolu ?]
Pour une raison qui m’échappe (mais je veux bien avoir l’explication !), dans la BOUCLE_inscrits #VOIR_REPONSE{hidden_2,valeur_uniquement}
ne renvoie pas xxh-yyh (qui est pourtant la valeur présente dans la base de donnée mais <p>xxh-yyh</p>
Du coup, la présence des balises fait que le test de comparaison ne peut jamais donner « vrai ».
J’ai tenté d’écrire #VOIR_REPONSE*{hidden_2,valeur_uniquement} mais sans effet.
Du coup j’ai fait appel au filtre |supprimer_tags
Question subsidiaire : dans la partie optionnelle de la boucle en question, j’ai écrit le code suivant dans l’idée d’introduire/expliquer le résultat de la boucle :
<h4>Sont déjà inscrit(e)s au poste #ENV{postname} pour le créneau #ENV{time}</h4>
Sur la page web produite, la valeur de #ENV{postname} est « collée » au mot suivant (en gras ci-dessous)
Exemple : Sont déjà inscrit(e)s au poste Brouzoufs Vendredipour le créneau 12h-14h
J’ai essayé sans résultat #ENV*{postname} et #ENV**{postname}, et je me suis rabattu pour l’instant sur un très vilain :
<h4>Sont déjà inscrit(e)s au poste #ENV{postname} pour le créneau #ENV{time}</h4>
Qu’est-ce qui est à l’origine du fait que l’espace qui suit la balise soit mangé sans autre forme de procès ?
Tu écris « Pour une raison qui m’échappe #VOIR_REPONSE{hidden_2,valeur_uniquement} renvoie <p>xxh-yyh</p> »
Alors
soit c’est le fonctionnement de #VOIR_REPONSE : tu as essayé les autres valeur de paramétrage que valeur_uniquement ?
soit c’est que toi tu ajoutes ces tags. Là il faut voir ton squelette et ce que tu mets dans le hidden.
Quant à « la valeur de #ENV{postname} est collée au mot suivant », c’est normal, toutes les balises mangent les espaces autour d’elles. Pour éviter cela il faut utiliser la syntaxe avec crochets parentheses, qui protège les espaces inclus dans les crochets et les espaces voisins en dehors des crochets.
Donc par exemple « valeur de [(#ENV{postname})] n'est plus collée ainsi ».
Ah, pas sûr de bien comprendre ce que tu souhaites que je te communiques :
1 - La boucle qui fonctionne mais dans laquelle la valeur de la balise VOIR_REPONSE est entourée de balise « paragraphe parasite »
<B_inscrits>
<h4>Sont déjà inscrit(e)s au poste [(#ENV{postname})] pour le créneau [(#ENV{time})]</h4>
<table><thead><tr><td>NOM</td></tr></thead><tbody>
<BOUCLE_inscrits(FORMULAIRES_REPONSES spip_formulaires_reponses_champs)
{id_formulaire=9}{nom=hidden_1}{valeur=#ENV{postname}}>
[<tr><td>[( (#VOIR_REPONSE{hidden_2,valeur_uniquement}|supprimer_tags|=={#ENV{time}}|oui)[(#VOIR_REPONSE{input_1,valeur_uniquement})]</td></tr>]
</BOUCLE_inscrits>
</tbody></table>
</B_inscrits>
le html produit :
<h4>Sont déjà inscrit(e)s au poste Billetterie 1 Samedi pour le créneau 18h00-20h30</h4>
<table><thead><tr><td>NOM</td></tr></thead><tbody>
<tr><td>1 - <p>DUPONT Jacques</p></td></tr><tr><td>2 - <p>DURAND Antoine</p></td></tr>
</tbody></table>
2 La boucle qui fonctionne et dans laquelle la balise « VOIR_REPONSE » renvoie la valeur du champ hidden sans être entourée de balise « paragraphe parasite »
<B_inscrits>
<h4>Sont déjà inscrit(e)s au poste [(#ENV{postname})] pour le créneau [(#ENV{time})]</h4>
<table><thead><tr><td>NOM</td></tr></thead><tbody>
<BOUCLE_inscrits(FORMULAIRES_REPONSES spip_formulaires_reponses_champs)
{id_formulaire=9}{nom=hidden_1}{valeur=#ENV{postname}}>
[<tr><td>[( (#VOIR_REPONSE{hidden_2,valeur_uniquement}|supprimer_tags|=={#ENV{time}}|oui)[(#VOIR_REPONSE{input_1,valeur_uniquement}|supprimer_tags)]</td></tr>]
</BOUCLE_inscrits>
</tbody></table>
</B_inscrits>
le html produit :
<h4>Sont déjà inscrit(e)s au poste Billetterie 1 Samedi pour le créneau 18h00-20h30</h4>
<table><thead><tr><td>NOM</td></tr></thead><tbody>
<tr><td>1 - DUPONT Jacques</td></tr><tr><td>2 - DURAND Antoine</td></tr>
</tbody></table>
Bon… en appliquant le filtre, ça marche alors on peut en rester là…
Mais là toujours tu partages le code de la récupération du hidden. C’est un bout du problème, le bout où la valeur sort et où tu t’apperçois que ya un p en trop. Ce que je te suggérais d’aller voir c’était le code qui donne sa valeur au hidden : le bout où la valeur rentre = le input hidden HTML du formulaire (et éventuellement le code SPIP qui génère, mais avec formidable, peut être ya pas).
Ben c’est ça : ce champ est déclaré dans formidable.
Dans le squelette, le formulaire est appelé de manière à remplir dynamiquement les deux champs cachés via les arguments passés dans l’url appelantes :
Aïe, aïe, aïe, caramba je suis perdu de savoir quoi te répondre… Je crois comprendre que tu cherches à préciser « le bout en amont », à savoir comment se remplit le hidden mais je ne vois pas quoi te dire de plus.
Si je récapitule :
Le formulaire est dans un squelette inscription.html
L’appel à inscription.html se fait par des liens de la forme : ruedesarts.net/?page=inscription&postname=le nom du poste &time=xxh-xxh
Formidable prend la main, remplit les champs hidden avec les arguments passés dans l’url appelante : #FORMULAIRE_FORMIDABLE{benevoles_2, #ARRAY{hidden_1, #ENV{postname},hidden_2, #ENV{time}}}
Ensuite, eh bien SPIP et Formidable sont dans un bateau et font leur petite cuisine ensemble
Dans la base de données le champ hidden contient bien (phpmyadmin) la valeur de postname MAIS lorsque dans un autre squelette j’interroge les réponses dans une boucle FORMULAIRES_REPONSES, [<tr><td>(#VOIR_REPONSE{input_1,valeur_uniquement})</td><tr>]
le html produit contient une balise p « parasite » <tr><td><p>le nom du poste</p></td></tr>
L’utilisation de supprimer_tags corrige
La question est de savoir qui prend l’initiative d’ajouter ces balises « p » sans qu’on ne lui ait rien demandé : SPIP ? la balise VOIR_REPONSE ?
Est-ce que tous les bouts sont là ou est-ce que je passe toujours à côté du quelque chose dont tu aurais besoin ?
