[spip-dev] bug ? Conditions et INCLURE posent problème

Dev
1

Bonjour à tous,

Je sais que je devrais d'abord poser ma question sur spip-user mais ça
ressemble plus à un bug qu'à une erreur de user, donc je vais aller
directement à la source...

Le problème court : je veux tester une condition et inclure
dynamiquement un squelette en fonction du résultat. Mais quand je
tente de faire passer un paramètre à l'inclusion, Spip m'envoie une
erreur MySQL, dans un squelette inclus qui ne comporte pas encore de
boucle !

Voilà l'histoire longue :

1. LE CONTEXTE

  <BOUCLE_principale(ARTICLES){id_article}>

2. UNE INCLUSION SIMPLE : OK

Dans la boucle principale, si j'inclus
<INCLURE{fond=inc/onglet_bas}{id_article}> pas de souci

3. UNE CONDITION ET DES INCLUSIONS SANS PARAMS : OK

Dans la boucle principale ça marche toujours :

  [(#GET{condition}|=={oui}|?{
  <INCLURE{fond=inc/onglet_bas}>

2

Tiens en revanche (une plombe plus tard) voilà une méthode qui marche :

  [(#GET{condition}|=={oui}|?{' ',''})
  <INCLURE{fond=inc/onglet_bas}{id_article}>
  ]

inspiré de : http://forum.spip.org/fr_218113.html
(ça ne gagne pas en lisibilité, en tout cas, surtout quand on empile
deux conditions dans ce genre-là l'une dans l'autre)

Mais il me semble qu'on a tout de même affaire à un truc qui a la
couleur du bug et l'odeur du bug, non ?

3

Le parseur a tendance à se prendre les pieds dans le tapis quand on mélange un peu trop les [({<
C'est une limite connue qui fait aussi partie des raisons du travail d'Emmanuel sur une nouvelle syntaxe.

Cédric

4

cedric.morin@yterium.com a écrit :

4. LA MÊME CONDITION AVEC UNE INCLUSION AVEC DES PARAMS : NO GO

       [(#GET{condition}|=={oui}|?{
       <INCLURE{fond=inc/onglet_bas}{id_article}>
       ,
       <!-- sinon rien à faire -->
       })]

Tiens en revanche (une plombe plus tard) voilà une méthode qui marche :

    [(#GET{condition}|=={oui}|?{' ',''})
    <INCLURE{fond=inc/onglet_bas}{id_article}>
    ]

inspiré de : http://forum.spip.org/fr_218113.html
(ça ne gagne pas en lisibilité, en tout cas, surtout quand on empile
deux conditions dans ce genre-là l'une dans l'autre)

Mais il me semble qu'on a tout de même affaire à un truc qui a la
couleur du bug et l'odeur du bug, non ?

Le parseur a tendance à se prendre les pieds dans le tapis quand on mélange un peu trop les [({<
C'est une limite connue qui fait aussi partie des raisons du travail d'Emmanuel sur une nouvelle syntaxe.

Cédric

Personnellement j'ai résolu en faisant :

#INCLURE quand j'ai besoin d'une condition en syntaxe de balisage => ça marche plutôt bien à condition de bien utiliser la syntaxe étendue [( )] pour toutes les expressions, et bien évidemment, c'est inclus inline.

Les boucles CONDITION de bonux quand j'ai besoin d'une inclusion dynamique.
Mais attention : il y a souvent des pertes de contexte dans les boucles CONDITION, je passe généralement les paramètres à l'INCLURE en les stockant avant dans des #SET afin d'être sûr qu'ils ne sont pas altérés par le passage dans la boucle (même avec un appel explicite #_toto:TRUC).
En plus de ça, le critère {si} des boucles CONDITION est souvent capricieux avec les tests un peu complexes (surtout ceux comportant des

ou et |et pour lesquels la vérification du parenthésage pète carrément)

=> je stocke le résultat de mon test dans un #SET, puis je le teste dans une CONDITION simple ensuite.

A bientôt
    Simon

5

Plus lisible, si tu n'as qu'une chose à faire :

[(#GET{condition}|=={oui}|oui)
  <INCLURE{fond=inc/onglet_bas}{id_article}>
]

Les filtres "oui" et "non" sont équivalents à "?{' ',''}" et "?{'',' '}"

-Nicolas

6

Salut,

Je rebondis sur le sujet du message de Stéphane. J'ai eu aussi à faire
face à ce "bug". Dans le même style de contexte :

Cela fonctionne avec des inclusions statiques :

[(#ENV{truc}|=={oui}|?{
  [(#INCLURE{fond=machin}{id_article})]