+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : register_globals ? (/showthread.php?tid=5178)
RE: register_globals ? - Argorate - 18-01-2011
Possible, je ne travail plus avec les register_globals à On depuis des années^^
C'est le mal incarné ce truc ! (je me souviens encore de mon long périple de recherche de bug dù a cette saloperie!)
Merci de la précision
RE: register_globals ? - Sephi-Chan - 18-01-2011
Et est-ce que tu utilises $GLOBALS ? Si oui, dans quel but ?
Sephi-Chan
RE: register_globals ? - Argorate - 19-01-2011
En l'occurrence pour stocker les paramètres d'environnement pour ne pas avoir a appelé la fonction a chaque fois, ça évite de refaire tout le traitement.
Pour savoir la profondeur de la page courante par rapport a la racine que je stock dans $GLOBALS pour que je puise avoir accès a cette info partout, sans chercher a savoir où je suis ni rappelé la fonction qui fait le traitement, ce qui est bien pratique
RE: register_globals ? - php_addict - 19-01-2011
(19-01-2011, 12:46 AM)Argorate a écrit : En l'occurrence pour stocker les paramètres d'environnement pour ne pas avoir a appelé la fonction a chaque fois, ça évite de refaire tout le traitement.
Pour savoir la profondeur de la page courante par rapport a la racine que je stock dans $GLOBALS pour que je puise avoir accès a cette info partout, sans chercher a savoir où je suis ni rappelé la fonction qui fait le traitement, ce qui est bien pratique
rien à voir avec ton soucis mais pourquoi ne pas faire ca aec les _SESSIONS ?
RE: register_globals ? - Argorate - 19-01-2011
Ca n'a rien avoir avec la session utilisateur: savoir si la page où l'on est nécessite "../../" (par exemple) pour les fichiers a inclure, n'a - à mon sens - rien a faire dans une session, ce n'est pas propre à la session de l'utilisateur... tu vois se que je veux dire?
RE: register_globals ? - Anthor - 19-01-2011
En général, c'est pour ça que l'on à des constantes, pour les infos qui ne CHANGENT PAS. Pas des variables globales, ni une session...
RE: register_globals ? - Argorate - 19-01-2011
Oui sauf que cela change justement, puisque c'est fonction de la page où tu es et que c'est le résultat d'un traitement.
Après utiliser des constantes ou des variables qui ne change pas, c'est exactement pareil pour moi, c'est juste une histoire de convention...
RE: register_globals ? - Anthor - 19-01-2011
(19-01-2011, 11:46 AM)Argorate a écrit : Oui sauf que cela change justement, puisque c'est fonction de la page où tu es et que c'est le résultat d'un traitement.La racine du site, c'est rarement variable quand on développe proprement ?
(19-01-2011, 11:46 AM)Argorate a écrit : Après utiliser des constantes ou des variables qui ne change pas, c'est exactement pareil pour moi, c'est juste une histoire de convention...Si tu le dis...
RE: register_globals ? - Argorate - 19-01-2011
Non ce n'est pas ça. Si tu es dans racine/index.php ou racine/regles/index.php ce n'est pas pareil pour inclure des fichiers ou images...
Je ne sais pas comment vous gérez ça (peut être a la main?) mais moi j'ai une fonction qui gère ça tout seul.
RE: register_globals ? - Jeckel - 19-01-2011
(19-01-2011, 01:17 AM)Argorate a écrit : Ca n'a rien avoir avec la session utilisateur: savoir si la page où l'on est nécessite "../../" (par exemple) pour les fichiers a inclure, n'a - à mon sens - rien a faire dans une session, ce n'est pas propre à la session de l'utilisateur... tu vois se que je veux dire?
Pour ce genre d'info, j'utilise plutot ce genre de code :
// Dans le fichier à la racine, on définit une constante avec le chemin absolu :
define('APP_BASE_PATH', dirname(__FILE__) . DIRECTORY_SEPARATOR);
// ensuite pour les includes :
include APP_BASE_PATH . 'include/lib/mon_fichier.inc.php';
L'avantage d'une constante par rapport à une variable globale, c'est que tu n'as pas de risque qu'elle soit écrasée plus tard...
Comme ça, jamais de soucis de "profondeur"
Sinon pour éviter les variables globales qui d'une part augmente considérablement le risque de bug mais sont aussi souvent à l'origine de faille de sécurité, un petite astuce est d'utiliser une classe de registre :
class Registre
{
// Espace de stockage de nos variables
private $_vars;
// Il s'agit d'un singleton, constructeur privé
private function __construct()
{
$this->_vars = array();
}
// Il s'agit toujours d'un singleton donc on évite le clonnage
public function __clone()
{
throw new Exception("Clonage d'un singleton interdit");
}
// Et donc pour récupéré l'objet :
static public function getInstance()
{
static $instance = null;
if (is_null($instance))
$instance = new self();
return $instance;
}
// le getter
public function __get($var)
{
return $this->_vars[$var];
}
// le setter
public function __set($var, $val)
{
$this->_vars[$var] = $val;
return $val;
}
// Tester si la variable existe
public function __isset($var)
{
return isset($this->_vars[$var]);
}
}
Et ensuite pour l'utiliser N'IMPORTE OU dans votre code, dans une fonction ou non :
// Affectation :
$registre = Registre::getInstance();
$registre->ma_var = 'test';
// ou alors :
Registre::getInstance->ma_var = 'test'; // identique
// plus loin, dans une fonction, pour lire la variable :
echo Registre::getInstance()->ma_var;
// ou alors :
$registre = Registre::getInstance();
echo $registre->ma_var;
// Et enfin vous pouvez même tester si la variable existe déjà :
$registre = Registre::getInstance();
if (isset($registre->ma_var))
{
echo $registre->ma_var;
}
Voilà, plus besoin de variables globales, c'est plus propre et plus sécurisé...