Erreurs de Base de
On ne se moque pas !
cela peut même arriver aux meilleurs ; mais cela vous servira !La question !
Pourquoi, dans ma boucle, le critère where avec un paramètre dynamique ne marche pas ?
C’est le cas classique d’une simple boucle avec un critère paramétré, habituellement valorisé ’en dur’ par un #SET{param,truc}, donc utilisé par exemple dans critère {where #GET{param}}, qui ne donne....
Alors que l’écriture ’en dur’ dans le même contexte de données
rajoute bien la clause WHERE au SQL résultant (et donc filtre correctement les données).
La bonne syntaxe
Bon, d’accord ; les puristes SPIP 3 feront remarquer que la bonne syntaxe normalisée pour le compilateur devrait comporter tous les séparateurs d’une expression complète, crochets et parenthèses :
Dans l’absolu, ce devrait être {where [(#GET{truc})]} ?
En fait vous pourriez vérifier que/si l’autre écriture [{where [(#GET{truc})}] n’est pas validée !
Bizarre pourtant, l’utilisation simplifiée {where #GET{truc}} n’a jamais causé de problèmes pourtant ??
L’explication
"oula je sens la coquille ultra conne" ;-)
mis le #SET juste avant la boucle, mais du coup dans sa partie conditionnelle [1] donc qui est compilée après
Pour mémoire, une boucle de balayage SQL peut avoir des parties conditionnelles affichées avant et après le corps de boucle, (en particulier souvenez-vous le #TOTAL_BOUCLE qui ne peut être calculé de façon optimisée qu’après exécution du SQL) :
- // schéma de principe d'une boucle SPIP
- #SET // à mettre avant toute la boucle !
- <B_sql>
- // partie conditionnelle avant
- #PAGINATION{#TOTAL_BOUCLE}
- <BOUCLE_sql(){critères #GET}>
- // corps de boucle
- </BOUCLE_sql>
- //partie conditionnelle après
- </B_sql>
- //partie conditionnelle alternative
- <//B_sql>
Que celui à qui cela n’est jamais arrivé.... Merci !
Article publié le 20 novembre 2020, et actualisé en novembre 2020 .
Répondre à cet article