[spip-dev] [pour info] Passage de variable php dans un squelette inclus cassé

Bonjour,

Depuis un bout de temps, je fais des choses (pas bien) comme ça :
Dans squelette1.html :
<?php $mavariable=1; ?>
<INCLURE{fond=squelette2}>

Et dans squelette2.html :
<?php if ($mavariable==1} { ?>

Depuis quelques jours, ça ne marche plus.

Bon, je vais passer en syntaxe pur SPIP (avec quelques inclures de plus).
Mais je suis surpris que ça ne marche plus.

Ci-joint, fichiers de test.

passage_variable.zip (360 Bytes)

* RealET tapuscrivait, le 18/09/2008 19:03:

Bon, je vais passer en syntaxe pur SPIP (avec quelques inclures de plus).

J'ai finalement utilisé des global ou $GLOBALS[''] pour aller vite.

la modification de ecrire/public.php qui fait maintenant appel a la fonction recuperer_fond a modifié le contexte d'execution des squelettes qui ne sont plus executés dans l'espace des globales mais dans l'espace d'une fonction.
Du coup, les variables sont implicitement locales et non globales.
Je ne sais pas si on peut y remédier, mais sinon, c'est une grave rupture de compatibilité avec une (mauvaise) pratique très répandue, datant de l'époque ou les variables internes a spip (#SET, #GET) n'étaient pas disponibles et ou il n'était pas toujours possible de faire autrement.

Pour ma part je connais plein de squelettes qui ont recours à cela, et si on décide de ne pas revenir en arrière, il faudra le signaler.
Cédric

cedric.morin@yterium.com a écrit :

Du coup, les variables sont implicitement locales et non globales.
Je ne sais pas si on peut y remédier, mais sinon, c'est une grave rupture de compatibilité avec une (mauvaise) pratique très répandue,

houuu !!

datant de l'époque ou les variables internes a spip (#SET, #GET) n'étaient pas disponibles et ou il n'était pas toujours possible de faire autrement.

ça c'est ben vrai ça...

Si c'est la "marche inéluctable du progrés",
on pourrait en atténuer les pénibles effets colatéraux
en fournissant "temporairement" un moyen optionnel
de déclarer les variables qui devraient être re-localisées
à l'entrée dans la fonction ?

Pour ma part je connais plein de squelettes qui ont recours à cela,

j'en doute pas ...
C'est parfois le plus simple car cela évite de devoir affronter frontalement
les arcanes parfois ardues de l'interaction intriquée avec le core.

et si on décide de ne pas revenir en arrière, il faudra le signaler.

hugh !

JL

Pas exactement: cela n'est vrai que pour les squelettes inclus.

Committo,Ergo:Sum

Je rappelle que le cas signalé comme ne marchant pas était l'horreur suivante:

<?php $mavariable=1; ?>
<INCLURE{fond=squelette2}>

ça ne concerne pas les scripts de premier niveau,
donc je ne suis pas sûr que ça concerne tellement de squelettes.

Committo,Ergo:Sum

Si, si je peux t'assurer que les affectation dans un squelette et les tests dans un squelette inclus sont une (très mauvaise) pratique malheureusement trop répandue...
J'en ai vu que trop, dans des squelettes sur mesure, mais aussi dans des squelettes très réutilisés.

Sinon, il est possible de s'en tirer en ecrivant explicitement
$GLOBALS['mavariable']=1;
dans le squelette.

Il faut juste décider que si l'on casse cela, on en est conscient, et on prévient.
Cédric

Si, si je peux t'assurer que les affectation dans un squelette et les tests dans un squelette inclus sont une (très mauvaise) pratique malheureusement trop répandue...

...

Il faut juste décider que si l'on casse cela, on en est conscient, et on prévient.

Je suis arrivé à l'état actuel de inc/public.php par partage de code, mais en regardant à nouveau il me semble déjà qu'on pourrait y remplacer recuperer_fond par evaluer_fond sans dommage sauf peut-$etre pour les langues où il faudrait recopier, mais c'est à vérifier. Partant, il faudrait isoler le bout de code autour de xml_hack dans evaluer_fond pour en faire une fonction, afin de ne plus appeler de fonction pour faire l'inclusion sans trop dupliquer de choses.
Bref, ce n'est pas la peine de créer des incompatibilités pour trop peu de gain, mais il faut que public.php reste d'une taille raisonnable pour qu'il ait des chances de rester dans le cache disque.

Committo,Ergo:Sum

* Committo,Ergo:sum tapuscrivait, le 19/09/2008 10:12:

je connais plein de squelettes qui ont recours à cela,

j'en doute pas ...
C'est parfois le plus simple car cela évite de devoir affronter frontalement
les arcanes parfois ardues de l'interaction intriquée avec le core.

et si on décide de ne pas revenir en arrière, il faudra le signaler.

Je rappelle que le cas signalé comme ne marchant pas était l'horreur suivante:

<?php $mavariable=1; ?>
<INCLURE{fond=squelette2}>

ça ne concerne pas les scripts de premier niveau,
donc je ne suis pas sûr que ça concerne tellement de squelettes.

En pratique, j'utilise ça pour passer :
- l'id de la rubrique courante
- l'id de l'article courant
- le titre de la page

Et ces éléments sont utilisés par le header et le footer de la page (et par des squelettes inclus eux-mêmes par ces derniers).

Bref, avant #SET, #GET, #ENV et {env} c'était extrêmement pratique.
Et le squelette SoyezCreateurs sur la zone en est truffé...