Spip utilise une gruge pour neutraliser le register_globals = false. Aprés un petit nettoyage, tous ce qui traine dans $_GET, $_PUT et $_COOKIE est bazardé dans $GLOBALS.
Attention, lorsque vous mettez du php dans vos jolis squelettes, pour éviter tout drame, il faut récuperer les variables externes de manières explicite, il est facile d'avoir des collisions avec les variables du compilo. Donc $_GET[toto] rulez plus que $toto .
Spip utilise une gruge pour neutraliser le register_globals = false.
Aprés un petit nettoyage, tous ce qui traine dans $_GET, $_PUT et
$_COOKIE est bazardé dans $GLOBALS.
Ce serait d'ailleurs à nettoyer puisque php>=4 ?
Attention, lorsque vous mettez du php dans vos jolis squelettes, pour
éviter tout drame, il faut récuperer les variables externes de manières
explicite, il est facile d'avoir des collisions avec les variables du
compilo. Donc $_GET[toto] rulez plus que $toto .
Spip utilise une gruge pour neutraliser le register_globals = false. Aprés un petit nettoyage, tous ce qui traine dans $_GET, $_PUT et $_COOKIE est bazardé dans $GLOBALS.
Ce serait d'ailleurs à nettoyer puisque php>=4 ?
oh oui, un $GLOBALS propre, et des appels explicites, comme le recommande PHP4 depuis la 4.jenesaispluscombien.
En plus, ça aide à la lisibilité du code.
Attention, lorsque vous mettez du php dans vos jolis squelettes, pour éviter tout drame, il faut récuperer les variables externes de manières explicite, il est facile d'avoir des collisions avec les variables du compilo. Donc $_GET[toto] rulez plus que $toto .
Ca sent le vécu :^)
Gros bugs qui pue à effet de bords. J'ai été sobre sur le mail.
oh oui, un $GLOBALS propre, et des appels explicites, comme le
recommande PHP4 depuis la 4.jenesaispluscombien.
En plus, ça aide à la lisibilité du code.
Tu proposerais quoi exactement ? Pour moi les $GLOBALS sont bien pratiques,
j'ai plein de scripts dans les squelettes qui les utilisent, je ne vois pas
les réécrire. Par contre on regarde peut-être un peu trop de variables au
début, non ?
oh oui, un $GLOBALS propre, et des appels explicites, comme le recommande PHP4 depuis la 4.jenesaispluscombien.
En plus, ça aide à la lisibilité du code.
Tu proposerais quoi exactement ? Pour moi les $GLOBALS sont bien pratiques,
j'ai plein de scripts dans les squelettes qui les utilisent, je ne vois pas
les réécrire. Par contre on regarde peut-être un peu trop de variables au
début, non ?
Oui, les globals ont une utilités, avoir des infos disponibles sur une même page plutot que de la calculer plusieurs fois. Mais plutot que de la charger systématiquement, le lazy loading (on charge à la demande) permet de limiter son usage. Par contre, coller le $_GET $_POST et $_COOKIES dans le global est une hérésie (officiel, l'avis d'excomunication est disponible sur le site PHP).
Quand tu fais un var_dump($GLOBALS), il ya pas mal de trucs dont on s'en fout un peu.
Il y a ensuite le soucis des collisions. Essayes pour voir d'utiliser $page comme globals, tu vas voir la tronche qu'il fait ton compilo. Comme on ne sait ce qu'il y a en global, on peut écrabouiller un truc important sans faire expres. Normalement, le code est censé être autonome et ne pas se taper dessus avec le voisin. L'usage des class (et des attributs) facilite cet isolement.
important sans faire expres. Normalement, le code est censé être
autonome et ne pas se taper dessus avec le voisin. L'usage des class (et
des attributs) facilite cet isolement.
Oui, peut-être en théorie *aurait-il fallu* faire comme ça ; mais en
pratique si on ne calcule plus $GLOBALS comme avant on va exploser nombre de
sites installés.
important sans faire expres. Normalement, le code est censé être autonome et ne pas se taper dessus avec le voisin. L'usage des class (et des attributs) facilite cet isolement.
Oui, peut-être en théorie *aurait-il fallu* faire comme ça ; mais en
pratique si on ne calcule plus $GLOBALS comme avant on va exploser nombre de
sites installés.
C'est pour leur bien ;-).
Déja, si les nouveautés sont plus économe de $GLOBALS, utilise des $_GET, ce sera déja une belle avancée.
Ensuite, il y aura bien une rupture avec un numéro de version, ce n'est pas en se trainant un gros tas de compatibilité depuis SPIP 1.0 que Spip va être véloce.
Déja, je soupsonne fortement les hacks du globals pour pas corriger partout lors de la décision du "register_globals = false", il va bien falloir évoluer.
Un peu comme les .php3 tout moche.
Ensuite, il y aura bien une rupture avec un numéro de version, ce n'est
pas en se trainant un gros tas de compatibilité depuis SPIP 1.0 que Spip
va être véloce.
Gros tas toi même
Non, je ne pense pas que cette boucle coûte cher en temps.
Déja, je soupsonne fortement les hacks du globals pour pas corriger
partout lors de la décision du "register_globals = false", il va bien
falloir évoluer.
Un peu comme les .php3 tout moche.
Tu proposerais quoi exactement ? Pour moi les $GLOBALS sont bien
pratiques,
j'ai plein de scripts dans les squelettes qui les utilisent, je ne vois
pas
les réécrire. Par contre on regarde peut-être un peu trop de variables au
début, non ?
Une fonction du genre :
function get($nom, $type='') {
if (!isset($_REQUEST)) return;
$var = $_REQUEST[$nom];
/* ici stripslashes éventuel si magic_quotes */
switch ($type) {
case 'id':
$var = intval($var);
break:
case 'str':
$var = strval($var):
break;
/* etc. */
}
$GLOBALS[$nom] = $var:
}
Avec au début de chaque script :
get('id_article', 'id')
get('ajout_forum')
etc.
Après les globales peuvent être injectées sauvagement lors de l'exécution
d'un squelette en cache, mais sans être injectées avant ni après. Ca
permet de garder la compatibilité avec les squelettes actuels.
Mais bon, si personne n'a jamais fait cela, c'est que c'est la croix et la
bannière pour migrer le code actuel.