[spip-dev] Boucle récursive

Dev
1

Bonjour,

Dans l'article http://www.spip.net/fr_article914.html on explique que « Le nouveau compilateur introduit par SPIP 1.8 considère que la notation <BOUCLEn(BOUCLEx)> à l’extérieur de la boucle x est vide de sens, ... »

Pourtant j'essaie exactement cela, et ça marche :

<BOUCLE_1(ARTICLES){id_article}>
<BOUCLE_2(RUBRIQUES){id_rubrique}{id_secteur=586}>
<BOUCLE_3(RUBRIQUES){id_trad=#ID_RUBRIQUE}{lang=#ENV{lang}}{tout}>

<BOUCLE_output(HIERARCHIE){id_rubrique}{tout}>blah blah blah</BOUCLE_getpath>

</BOUCLE_3>
</BOUCLE_2>
  <BOUCLE_calloutput(BOUCLE_output)></BOUCLE_calloutput>
<//B_2>
</BOUCLE_1>

(J'ai ajouté un champ id_trad sur les rubriques.)

Est-ce que la documentation n'est plus à jour ?
Ou est-ce que cela marche un peu par hazard et je ne devrais pas
me fier à ce comportement.

merci !
Paolo

2

Bonjour Paolo

3

Committo,Ergo:sum wrote:

Ta boucle output n'est pas fermée, je doute que ce soit ça le squelette complet car chez moi ça dénonce cette erreur.

Pardon -- en changeant les noms des boucles pour rendre le code plus clair/abstrait j'ai raté un changement. Ça devrait être :

<BOUCLE_1(ARTICLES){id_article}>
<BOUCLE_2(RUBRIQUES){id_rubrique}{id_secteur=586}>
<BOUCLE_3(RUBRIQUES){id_trad=#ID_RUBRIQUE}{lang=#ENV{lang}}{tout}>

<BOUCLE_output(HIERARCHIE){id_rubrique}{tout}>blah blah blah</BOUCLE_output>

</BOUCLE_3>
</BOUCLE_2>
     <BOUCLE_calloutput(BOUCLE_output)></BOUCLE_calloutput>
<//B_2>
</BOUCLE_1>

Paolo

4

J'ai employé l'expression "vide de sens" plutôt que "erronée", parce qu'il existe des cas où le code produit par le compilateur va effectuer de mauvais calculs. Dans la mesure où la plupart des utilisations allaient tomber sur des cas sans ce problème, j'ai préféré continuer à les accepter plutôt que de déclencher une erreur et casser la compatibilité.

Pour ton exemple particulier:

<BOUCLE_1(ARTICLES){id_article}>
<BOUCLE_2(RUBRIQUES){id_rubrique}{id_secteur=586}>
<BOUCLE_3(RUBRIQUES){id_trad=#ID_RUBRIQUE}{lang=#ENV{lang}}{tout}>

<BOUCLE_output(HIERARCHIE){id_rubrique}{tout}>blah blah blah</BOUCLE_output>

</BOUCLE_3>
</BOUCLE_2>
   <BOUCLE_calloutput(BOUCLE_output)></BOUCLE_calloutput>
<//B_2>
</BOUCLE_1>

La "boucle" calloutput revient à une inclusion d'un squelette qui comporterait uniquement la boucle ouput, sauf que contrairement à une inclusion habituelle on ne donne pas l'environnement, soit ici la valeur de id_rubrique qui est inconnue. C'est en ça que cette inclusion déguisée est "vide de sens". Elle donne peut-être ce que tu veux, mais ce ne sera peut-être pas le cas avec une version future de SPIP, puisqu'il est dit que SPIP ne sait pas donner un sens à cette écriture, et donc que le résultat est aléatoire.

Committo,Ergo:Sum

5

Committo,Ergo:sum wrote:

Elle donne peut-être ce que tu veux, mais ce ne sera peut-être pas le cas avec une version future de SPIP, puisqu'il est dit que SPIP ne sait pas donner un sens à cette écriture, et donc que le résultat est aléatoire.

Ok, merci bcp. Je vais plutôt éviter cette écriture alors.

Paolo

6

La "boucle" calloutput revient à une inclusion d'un squelette
qui comporterait uniquement la boucle ouput, sauf que
contrairement à une inclusion habituelle on ne donne pas
l'environnement, soit ici la valeur de id_rubrique qui est
inconnue. C'est en ça que cette inclusion déguisée est "vide
de sens". Elle donne peut-être ce que tu veux, mais ce ne
sera peut-être pas le cas avec une version future de SPIP,
puisqu'il est dit que SPIP ne sait pas donner un sens à cette
écriture, et donc que le résultat est aléatoire.

Mince, c'est pourtant hyper pratique comme écriture !

Comment est-ce qu'on devrait écrire cette boucle dans un langage SPIP
correct ?

7

La "boucle" calloutput revient à une inclusion d'un squelette
qui comporterait uniquement la boucle ouput, sauf que
contrairement à une inclusion habituelle on ne donne pas
l'environnement, soit ici la valeur de id_rubrique qui est
inconnue. C'est en ça que cette inclusion déguisée est "vide
de sens". Elle donne peut-être ce que tu veux, mais ce ne
sera peut-être pas le cas avec une version future de SPIP,
puisqu'il est dit que SPIP ne sait pas donner un sens à cette
écriture, et donc que le résultat est aléatoire.

Mince, c'est pourtant hyper pratique comme écriture !

Non, parce qu'il y a une ambiguîté sur la valeur de l'environnement:
c'est la fausse bonne idée type.

Comment est-ce qu'on devrait écrire cette boucle dans un langage SPIP
correct ?

Par une inclusion.

Committo,Ergo:Sum