[spip-dev] $auteur_session

Bonsoir,

Il me semble que la notation historique pour tester une session :

  <?php if ($auteur_session) { ?>

Ne fonctionne plus ou plus correctement avec SPIP SVN (mais c'est
peut-être parce que ces éléments se trouvent dans des morceaux de
squelettes inclus). Est-ce qu'une autre notation est préférable ?

François

Il me semble que la notation historique pour tester une session :

       <?php if ($auteur_session) { ?>

Ne fonctionne plus ou plus correctement avec SPIP SVN (mais c'est
peut-être parce que ces éléments se trouvent dans des morceaux de
squelettes inclus). Est-ce qu'une autre notation est préférable ?

Les squelettes ne sont plus évalués en global mais à l'intéreur d'une
fonction, du coup il faut que tu utilises
  <?php if ($GLOBALS['auteur_session']) { ?>

C'est d'ailleurs une régression assez gênante, je trouve.

Sinon auteur_session existe si et seulement si visiteur_session a un
statut ; mais la "vraie" variable de session désormais c'est
visiteur_session -- dont on peut tester le statut pour retrouver la
sécurité d'avant.

-- Fil

Cédric

Il me semble que la notation historique pour tester une session :

       <?php if ($auteur_session) { ?>

Ne fonctionne plus ou plus correctement avec SPIP SVN (mais c'est
peut-être parce que ces éléments se trouvent dans des morceaux de
squelettes inclus). Est-ce qu'une autre notation est préférable ?

Les squelettes ne sont plus évalués en global mais à l'intéreur d'une
fonction, du coup il faut que tu utilises
  <?php if ($GLOBALS['auteur_session']) { ?>

C'est d'ailleurs une régression assez gênante, je trouve.

on avait discuté de savoir si oui on non maintenir la regression :stuck_out_tongue:

Je pense que c'est le moment ou jamais de l'introduire, et que rester dans une evaluation en globale est assez penalisant pour la factorisation du code.
J'avoue ne pas avoir relancé le débat car je suis plutot pour cette regression qui oblige aussi a passer par les #ENV plutot que de transmettre des globales de skel en skel en dépit du bon sens.

Cédric

J'allais le dire.

Committo,Ergo:Sum

* Emmanuel Saint-James tapuscrivait, le 10/11/2008 19:59:

Les squelettes ne sont plus évalués en global mais à l'intéreur d'une
fonction, du coup il faut que tu utilises
<?php if ($GLOBALS['auteur_session']) { ?>

C'est d'ailleurs une régression assez gênante, je trouve.

J'avoue ne pas avoir relancé le débat car je suis plutot pour cette regression qui oblige aussi a passer par les #ENV plutot que de transmettre des globales de skel en skel en dépit du bon sens.

J'allais le dire.

Du coup, j'ai googlé pour trouver http://blog.emmanueldeloget.com/index.php/2006/10/05/17-l-heresie-des-variables-globales
Lecture fort intéressante !

Pour en revenir aux #ENV et {env}
J'avais pensé naïvement que {env} passait en paramètres tous ce que le modèle ou la noisette avait déjà reçu.
Que néni !
http://permalink.gmane.org/gmane.comp.web.spip.devel/50617 rapporte :

Cédric

* Emmanuel Saint-James tapuscrivait, le 10/11/2008 19:59:

Les squelettes ne sont plus évalués en global mais à l'intéreur d'une
fonction, du coup il faut que tu utilises
<?php if ($GLOBALS['auteur_session']) { ?>

C'est d'ailleurs une régression assez gênante, je trouve.

J'avoue ne pas avoir relancé le débat car je suis plutot pour cette regression qui oblige aussi a passer par les #ENV plutot que de transmettre des globales de skel en skel en dépit du bon sens.

J'allais le dire.

Du coup, j'ai googlé pour trouver http://blog.emmanueldeloget.com/index.php/2006/10/05/17-l-heresie-des-variables-globales
Lecture fort intéressante !

Pour en revenir aux #ENV et {env}
J'avais pensé naïvement que {env} passait en paramètres tous ce que le modèle ou la noisette avait déjà reçu.
Que néni !
http://permalink.gmane.org/gmane.comp.web.spip.devel/50617 rapporte :

et http://permalink.gmane.org/gmane.comp.web.spip.devel/50617 contient la réponse dans la question (comme pour les problèmes scolaires).
Je cite
"D'après ce que j'avais compris, {env} pour un INCLURE permet de passer
tous les paramètres courant."

et je lis ensuite

[(#MODELE{m1}{env})]

La conclusion s'impose d'elle même :
#MODELE n'est pas #INCLURE

Cédric

* cedric.morin@yterium.com tapuscrivait, le 10/11/2008 21:58:

Cédric

* Emmanuel Saint-James tapuscrivait, le 10/11/2008 19:59:

Les squelettes ne sont plus évalués en global mais à l'intéreur d'une
fonction, du coup il faut que tu utilises
<?php if ($GLOBALS['auteur_session']) { ?>

C'est d'ailleurs une régression assez gênante, je trouve.

J'avoue ne pas avoir relancé le débat car je suis plutot pour cette regression qui oblige aussi a passer par les #ENV plutot que de transmettre des globales de skel en skel en dépit du bon sens.

J'allais le dire.

Du coup, j'ai googlé pour trouver http://blog.emmanueldeloget.com/index.php/2006/10/05/17-l-heresie-des-variables-globales

Lecture fort intéressante !

Pour en revenir aux #ENV et {env}
J'avais pensé naïvement que {env} passait en paramètres tous ce que le modèle ou la noisette avait déjà reçu.
Que néni !
http://permalink.gmane.org/gmane.comp.web.spip.devel/50617 rapporte :

et http://permalink.gmane.org/gmane.comp.web.spip.devel/50617 contient la réponse dans la question (comme pour les problèmes scolaires).
Je cite
"D'après ce que j'avais compris, {env} pour un INCLURE permet de passer
tous les paramètres courant."

et je lis ensuite

[(#MODELE{m1}{env})]

La conclusion s'impose d'elle même :
#MODELE n'est pas #INCLURE

Certes, #MODELE n'est pas #INCLURE.
Mais comme #INCLURE a été historiquement crée juste après #MODELE en en reprenant la syntaxe, il me semblait logique de les considérer comme équivalentes dans un squelette (dans un article, seul le modèle peut être appelé, je sais).
Donc, que {env} depuis un modèle fonctionne différemment que depuis une noisette me semble une rupture fonctionnelle difficile à expliquer/documenter.