{unique} et boucle IF

Pascal_BOYER · Octobre 25, 2005, 5:11

Bonsoir,

Je rencontre un problème avec l'utilisation du filtre {unique}

J'ai à peu près ceci:

<?php
if xxxxx {
?>
<BOUCLE_titre_rubiques(RUBRIQUES){id_rubrique}{par titre}{unique}
#TITRE
</BOUCLE_titre_rubiques>
<?php
}
else {
?>
<BOUCLE_titre_rubiques(RUBRIQUES){id_rubrique}{par titre}{unique}
#TITRE
</BOUCLE_titre_rubiques>
<?php
}

Et bien sûr, dans le else, le fitre {unique} fait que rien ne s'affiche car il
est déjà présent dans le if.

Y a t-il un moyen de contourner ce problème ?
Et pourquoi SPIP tient-il compte du premier {unique} alors qu'on ne rentre pas
forcément dans le if ? Donc il me semblerait logique que si on rentre dans le
else alors {unique} soit pris en compte.

Pascal

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Jacques_PYRAT3 · Octobre 25, 2005, 5:50

pascal@linuxorable.net a écrit :

Bonsoir,

Je rencontre un problème avec l'utilisation du filtre {unique}

J'ai à peu près ceci:

<?php
if xxxxx {
?>
<BOUCLE_titre_rubiques(RUBRIQUES){id_rubrique}{par titre}{unique}
#TITRE
</BOUCLE_titre_rubiques>
<?php
}
else {
?>
<BOUCLE_titre_rubiques(RUBRIQUES){id_rubrique}{par titre}{unique}
#TITRE
</BOUCLE_titre_rubiques>
<?php
}

Et bien sûr, dans le else, le fitre {unique} fait que rien ne s'affiche car il
est déjà présent dans le if.

Y a t-il un moyen de contourner ce problème ?
Et pourquoi SPIP tient-il compte du premier {unique} alors qu'on ne rentre pas
forcément dans le if ? Donc il me semblerait logique que si on rentre dans le
else alors {unique} soit pris en compte.

Tout simplement parce que le php que tu mets dans les squelettes est exécuté *après* les boucles (au moment où la page est demandée par l'internaute, le résultat des boucles étant quant à lui stocké dans le cache).

Pour plus d'explications : SPIP, PHP et Javascript sont dans un bateau - SPIP-Contrib

Jacques — www.pyrat.net

Mortimer_Porte · Octobre 25, 2005, 6:10

pascal@linuxorable.net wrote:

Bonsoir,

Je rencontre un problème avec l'utilisation du filtre {unique}

J'ai à peu près ceci:

<?php
if xxxxx {
?>
<BOUCLE_titre_rubiques(RUBRIQUES){id_rubrique}{par titre}{unique}
#TITRE
</BOUCLE_titre_rubiques>
<?php
}
else {
?>
<BOUCLE_titre_rubiques(RUBRIQUES){id_rubrique}{par titre}{unique}
#TITRE
</BOUCLE_titre_rubiques>
<?php
}

Et bien sûr, dans le else, le fitre {unique} fait que rien ne s'affiche car il
est déjà présent dans le if.

Y a t-il un moyen de contourner ce problème ?
Et pourquoi SPIP tient-il compte du premier {unique} alors qu'on ne rentre pas
forcément dans le if ? Donc il me semblerait logique que si on rentre dans le
else alors {unique} soit pris en compte.

J'arrete pas de vous le dire que le php, dans les squelettes, ça vous cosera plus de problèmes que ça n'en résoudra

il faut se mettre dans la logique SPIP et proscrire tout PHP de vos squelettes. C'est totalement faisable, ça prend qq gymnastiques du cerveau, mais à terme, c'est bien plus viable

Pierre
PS: si tu nous dis ce que tu veux faire, peut être qu'on pourra t'aider à le faire en SPIP

Pascal_BOYER · Octobre 25, 2005, 6:11

Quoting Jacques PYRAT <spip.newsgroup@pyrat.net>:

Tout simplement parce que le php que tu mets dans les squelettes est
exécuté *après* les boucles (au moment où la page est demandée par
l'internaute, le résultat des boucles étant quant à lui stocké dans le
cache).

Pour plus d'explications :
SPIP, PHP et Javascript sont dans un bateau - SPIP-Contrib

Jacques -- www.pyrat.net

Et bien c'est vraiment dommage car cela remplissait exactement la fonction que
je voulais et que je n'arrive pas à faire autrement.

En tout cas je m'en souviendrai.

Merci bien

Pascal

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Bruno_Desthuilliers2 · Octobre 25, 2005, 8:25

Pierre Andrews a écrit :

pascal@linuxorable.net wrote:

Bonsoir,

Je rencontre un problème avec l'utilisation du filtre {unique}

J'ai à peu près ceci:

<?php
if xxxxx {
?>
<BOUCLE_titre_rubiques(RUBRIQUES){id_rubrique}{par titre}{unique}
#TITRE
</BOUCLE_titre_rubiques>
<?php
}
else {
?>
<BOUCLE_titre_rubiques(RUBRIQUES){id_rubrique}{par titre}{unique}
#TITRE
</BOUCLE_titre_rubiques>
<?php
}

Et bien sûr, dans le else, le fitre {unique} fait que rien ne s'affiche car il
est déjà présent dans le if.

Y a t-il un moyen de contourner ce problème ?
Et pourquoi SPIP tient-il compte du premier {unique} alors qu'on ne rentre pas
forcément dans le if ? Donc il me semblerait logique que si on rentre dans le
else alors {unique} soit pris en compte.

J'arrete pas de vous le dire que le php, dans les squelettes, ça vous cosera plus de problèmes que ça n'en résoudra

il faut se mettre dans la logique SPIP et proscrire tout PHP de vos squelettes. C'est totalement faisable, ça prend qq gymnastiques du
cerveau, mais à terme, c'est bien plus viable

Pas d'accord.

D'une part, non, on ne peut pas *tout* résoudre uniquement avec les boucles spip, ou du moins pas d'une façon viable (maintenance et perfs). D'autre part, le problème n'est pas de mettre ou non du php dans les squelettes, mais d'avoir une compréhension suffisante du fonctionnement de spip, de php, et de la programmation web en général.

"proscrire php des squelettes" est une règle aussi arbitraire et dénuée de fondement que "pas de goto" (programmation structurée) ou "pas d'attributs publics" (programmation objet).

Pierre
PS: si tu nous dis ce que tu veux faire, peut être qu'on pourra t'aider à le faire en SPIP

Avec ou sans PHP, selon le besoin !-)

anon3638017 · Octobre 25, 2005, 7:49

On 25 Oct, 2005, at 21:25, bruno modulix wrote:

J'arrete pas de vous le dire que le php, dans les squelettes, ça vous cosera plus de problèmes que ça n'en résoudra
il faut se mettre dans la logique SPIP et proscrire tout PHP de vos squelettes. C'est totalement faisable, ça prend qq gymnastiques du
cerveau, mais à terme, c'est bien plus viable

Pas d'accord.

D'une part, non, on ne peut pas *tout* résoudre uniquement avec les boucles spip, ou du moins pas d'une façon viable (maintenance et perfs). D'autre part, le problème n'est pas de mettre ou non du php dans les squelettes, mais d'avoir une compréhension suffisante du fonctionnement de spip, de php, et de la programmation web en général.

"proscrire php des squelettes" est une règle aussi arbitraire et dénuée de fondement que "pas de goto" (programmation structurée) ou "pas d'attributs publics" (programmation objet).

Ha, les discussions religieuses... toujours difficile

Pierre

Bruno_Desthuilliers2 · Octobre 25, 2005, 11:41

Pierre Andrews a écrit :

On 25 Oct, 2005, at 21:25, bruno modulix wrote:

J'arrete pas de vous le dire que le php, dans les squelettes, ça vous cosera plus de problèmes que ça n'en résoudra
il faut se mettre dans la logique SPIP et proscrire tout PHP de vos squelettes. C'est totalement faisable, ça prend qq gymnastiques du
cerveau, mais à terme, c'est bien plus viable

Pas d'accord.

D'une part, non, on ne peut pas *tout* résoudre uniquement avec les boucles spip, ou du moins pas d'une façon viable (maintenance et perfs). D'autre part, le problème n'est pas de mettre ou non du php dans les squelettes, mais d'avoir une compréhension suffisante du fonctionnement de spip, de php, et de la programmation web en général.

"proscrire php des squelettes" est une règle aussi arbitraire et dénuée de fondement que "pas de goto" (programmation structurée) ou "pas d'attributs publics" (programmation objet).

Ha, les discussions religieuses... toujours difficile

Excuse-moi, mais autant je vois ce qu'il y a de dogmatique dans ton propos, autant le mien me semble avant tout pragmatique. Rien de religieux là-dedans (en ce qui me concerne du moins), si ce n'est le souci de ne pas faire d'un conseil de bon sens (ie : "si vous ne comprenez pas comment Spip gère une requête HTTP, ne vous rajoutez pas des complications supplémentaires en y ajoutant du php") un absolu dogmatique (ie : "il faut proscrire tout php de vos squelettes").

En bref : le sabbat est fait pour l'homme, pas l'homme pour le sabbat !-)

615beda9217b323297ed · Octobre 26, 2005, 6:34

On Tue, 2005-10-25 at 20:11 +0200, pascal@linuxorable.net wrote:

Et bien c'est vraiment dommage car cela remplissait exactement la fonction que
je voulais et que je n'arrive pas à faire autrement.

Si la condition du if n'est pas trop complexe, et qu'elle est
exprimable en spip, tu peux peut être t'en sortir avec la "boucle IF" de
cette contrib : http://www.spip-contrib.net/ecrire/articles.php3?id_article=1131

--
À+, Pif

b93dd7954ae1f3139a8d · Octobre 26, 2005, 10:52

J'arrete pas de vous le dire que le php, dans les squelettes, ça vous
cosera plus de problèmes que ça n'en résoudra

il faut se mettre dans la logique SPIP et proscrire tout PHP de vos
squelettes. C'est totalement faisable, ça prend qq gymnastiques du
cerveau, mais à terme, c'est bien plus viable

Pas d'accord.

D'une part, non, on ne peut pas *tout* résoudre uniquement avec les
boucles spip, ou du moins pas d'une façon viable (maintenance et perfs).
D'autre part, le problème n'est pas de mettre ou non du php dans les
squelettes, mais d'avoir une compréhension suffisante du fonctionnement
de spip, de php, et de la programmation web en général.

"proscrire php des squelettes" est une règle aussi arbitraire et dénuée
de fondement que "pas de goto" (programmation structurée) ou "pas
d'attributs publics" (programmation objet).

gérer des squelettes avec des instructions php dedans est à la longue plus compliqué, et on ne bénéficie pas du cache de spip
on peut souvent s'en sortir avec des boucles (parfois tordues il est vrai) et/ou des filtres (qui sont des fonctions php!), et chaque version de spip permet de simplifier ses squelettes (par exemple la balise EXPOSER m'a permis de virer plein de code php...)

vous faites ce que vous voulez bien sûr, mais c'est ainsi qu'est fondée la logique de spip (cf. liste des developpeurs...), ce n'est pas un dogme !!! plutôt un conseil pour faciliter la vie des débutants... bon on va pas "troller" sur le sujet non plus

Dorian

Bruno_Desthuilliers2 · Octobre 26, 2005, 10:17

ddorian@gmail.com a écrit :

J'arrete pas de vous le dire que le php, dans les squelettes, ça vous
cosera plus de problèmes que ça n'en résoudra

il faut se mettre dans la logique SPIP et proscrire tout PHP de vos
squelettes. C'est totalement faisable, ça prend qq gymnastiques du
cerveau, mais à terme, c'est bien plus viable

Pas d'accord.

D'une part, non, on ne peut pas *tout* résoudre uniquement avec les
boucles spip, ou du moins pas d'une façon viable (maintenance et perfs).
D'autre part, le problème n'est pas de mettre ou non du php dans les
squelettes, mais d'avoir une compréhension suffisante du fonctionnement
de spip, de php, et de la programmation web en général.

"proscrire php des squelettes" est une règle aussi arbitraire et dénuée
de fondement que "pas de goto" (programmation structurée) ou "pas
d'attributs publics" (programmation objet).

gérer des squelettes avec des instructions php dedans est à la longue plus compliqué,

Pourquoi, et pour qui ?

et on ne bénéficie pas du cache de spip

Chapitre et verset, STP ?

Pour ce que j'en ai vu, le compilo spip injecte lui-même du code PHP dans ce qu'il génère (résultat de la 'compilation' de <INCLURE>).

Ceci étant, on a plusieurs sites spip qui tournent en prod sans cache, et ma foi ça ne semble pas être un pb majeur... L'essentiel du boulot est déjà fait (traduction Spip -> php, aka 'compilation'), le reste est du php normal et les temps d'exécution sont parfaitement raisonnables (en tous cas sur un serveur décent... mais bon, si le serveur ne suit pas, tu pourra mettre tous les caches que tu veux, ça ne résoudra pas grand chose).

on peut souvent s'en sortir avec des boucles (parfois tordues il est vrai)

"plus compliqué", disions nous ?-)

et/ou des filtres (qui sont des fonctions php!),

Je sais, j'en écris souvent. Des balises aussi, et ça simplifie bien la vie également - au moins à l'intégrateur.

et chaque version de spip permet de simplifier ses squelettes (par exemple la balise EXPOSER m'a permis de virer plein de code php...)

+1

vous faites ce que vous voulez bien sûr, mais c'est ainsi qu'est fondée la logique de spip (cf. liste des developpeurs...), ce n'est pas un dogme !!! plutôt un conseil pour faciliter la vie des débutants...

Je ne dis pas qu'il faille réimplémenter la moitié de Spip en php dans chaque squelette, ce serait inepte. Dans ce cas, autant tout faire à la mimine. Et dans la mesure du possible, je préfère fournir à l'intégrateur une extention à la syntaxe Spip plutôt qu'un bout de PHP qu'il ne pourra pas s'approprier.

Je suis également d'accord - et je pense l'avoir clairement exprimé - sur le principe selon lequel il vaut mieux commencer par comprendre comment fonctionne Spip avant de vouloir mettre du php dans un squelette. Ce qui me fait réagir, c'est la formulation un poil extrême(iste). Non, il faut pas "proscrire tout php" des squelettes. Il faut juste s'en servir à bon escient.

bon on va pas "troller" sur le sujet non plus

Olivier_GENDRIN · Octobre 27, 2005, 9:06

> gérer des squelettes avec des instructions php dedans est à
la longue
> plus compliqué,

Pourquoi, et pour qui ?

Pour le webmestre par exemple.

> et on ne bénéficie pas du cache de spip

Chapitre et verset, STP ?

En gros, le code PHP sera mis en cache, et recalculé à chaque appel de la
page. On ne bénéficie dons pas du cache du point de vue de la charge de
calcul du PHP pour le serveur.

Pour ce que j'en ai vu, le compilo spip injecte lui-même du
code PHP dans ce qu'il génère (résultat de la 'compilation'
de <INCLURE>).

Ah bon ? Je n'ai jamais vu ça dans les pages affichées par SPIP. Tu aurais
un site où l'on pourrait voir ça (avec les squelettes afférents) ?

Ceci étant, on a plusieurs sites spip qui tournent en prod
sans cache, et ma foi ça ne semble pas être un pb majeur...
L'essentiel du boulot est déjà fait (traduction Spip -> php,
aka 'compilation'), le reste est du php normal et les temps
d'exécution sont parfaitement raisonnables (en tous cas sur
un serveur décent... mais bon, si le serveur ne suit pas, tu
pourra mettre tous les caches que tu veux, ça ne résoudra pas
grand chose).

Ben justement si. Il sera plus simple au server de servir une page déjà
calculée plutôt que de devoir tout recalculer. C'est un phénoméne testé avec
succés par beaucoup de monde sur les serveurs de free.

Je suis également d'accord - et je pense l'avoir clairement exprimé -
sur le principe selon lequel il vaut mieux commencer par comprendre
comment fonctionne Spip avant de vouloir mettre du php dans un
squelette. Ce qui me fait réagir, c'est la formulation un poil
extrême(iste). Non, il faut pas "proscrire tout php" des
squelettes. Il faut juste s'en servir à bon escient.

A bon escient, c'est-à-dire si on ne peut pas développer la chose en SPIP
dans un temps équivalent (en tenant compte des difficultés de maintenance et
de charge serveur). Mais en général, une fois qu'on a bien compris le
fonctionnement des boucles et des filtres, ça ne prends pas plus de temps de
mettre le PHP dans un filtre que de le mettre dans le squelette.

> bon
> on va pas "troller" sur le sujet non plus

<troll>
Mais si, mais si !-)
</troll>

Tiens, j'aurais ouvert ta balise troll au début de ton mail, mais bon...

Bruno_Desthuilliers2 · Octobre 27, 2005, 2:02

Olivier GENDRIN wrote:

gérer des squelettes avec des instructions php dedans est à

la longue

plus compliqué,

Pourquoi, et pour qui ?

Pour le webmestre par exemple.

<mauvaise-foi>
Là, ça dépend du webmestre !-)
</mauvaise-foi>

et on ne bénéficie pas du cache de spip

Chapitre et verset, STP ?

SPIP, PHP et Javascript sont dans un bateau - SPIP-Contrib

En gros, le code PHP sera mis en cache, et recalculé à chaque appel de la
page. On ne bénéficie dons pas du cache du point de vue de la charge de
calcul du PHP pour le serveur.

A moins que tu ne réécrives un CMS complet dans tes squelettes, c'est suffisamment minime pour ne pas être un problème.

Pour ce que j'en ai vu, le compilo spip injecte lui-même du code PHP dans ce qu'il génère (résultat de la 'compilation' de <INCLURE>).

Ah bon ? Je n'ai jamais vu ça dans les pages affichées par SPIP. Tu aurais
un site où l'on pourrait voir ça (avec les squelettes afférents) ?

sur ton install spip, dans CACHE, tous les fichiers skel_htmlXXXXX

Ceci étant, on a plusieurs sites spip qui tournent en prod sans cache, et ma foi ça ne semble pas être un pb majeur... L'essentiel du boulot est déjà fait (traduction Spip -> php, aka 'compilation'), le reste est du php normal et les temps d'exécution sont parfaitement raisonnables (en tous cas sur un serveur décent... mais bon, si le serveur ne suit pas, tu pourra mettre tous les caches que tu veux, ça ne résoudra pas grand chose).

Ben justement si. Il sera plus simple au server de servir une page déjà
calculée plutôt que de devoir tout recalculer. C'est un phénoméne testé avec
succés par beaucoup de monde sur les serveurs de free.

Je te parles de serveur *décent*. Les serveurs de chez free sont tellement à genoux que même servir une page statique leur prend des heures.

Je suis également d'accord - et je pense l'avoir clairement exprimé - sur le principe selon lequel il vaut mieux commencer par comprendre comment fonctionne Spip avant de vouloir mettre du php dans un squelette. Ce qui me fait réagir, c'est la formulation un poil extrême(iste). Non, il faut pas "proscrire tout php" des squelettes. Il faut juste s'en servir à bon escient.

A bon escient, c'est-à-dire si on ne peut pas développer la chose en SPIP
dans un temps équivalent (en tenant compte des difficultés de maintenance et
de charge serveur).

Exactly.

Mais en général, une fois qu'on a bien compris le
fonctionnement des boucles et des filtres, ça ne prends pas plus de temps de
mettre le PHP dans un filtre que de le mettre dans le squelette.

Si c'est pour faire un filtre, ça n'a de toutes façons rien à faire dans le squelette. Il y a d'autres usage à PHP dans spip que les filtres. Bon, il est clair que depuis qu'on peut créer ses balises et ses boucles, il y a beaucoup moins besoin de php dans les squelettes, et c'est une bonne chose.

bon on va pas "troller" sur le sujet non plus

<troll>
Mais si, mais si !-)
</troll>

Tiens, j'aurais ouvert ta balise troll au début de ton mail, mais bon...

Tu n'a pas dû subir beaucoups de trolls dans ta vie alors !-)