Discussion :

[Malikak]

Bonjour,

Je suis en train de developper un script complet, et celui-ci s'appuit sur des dizaines de variables de configuration (permettant par exemple de configurer le domaine de cookie, la durée maximale d'inactivité des sessions, ou encore le nombre de messages par page).

J'ai donc besoin d'accéder à ces variables partout dans mon script : à l'interieur des pages, à l'interieur des fonctions, mais aussi à l'interieur de quelques objets. Je me demandais alors comment définir ces variables.

Une idée serait de les définir en global, et d'y accéder ensuite par le tableau $_GLOBALS, mais d'après ce qu'on m'a dit ici, des variables globales n'avaient pas beaucoup de sens dans des fonctions, et encore moins dans des objets.

Cependant, il est presque inconcevable de devoir les passer en argument à chaque fonction. Sinon, une fonction getcookie() s'occupant de la lecture d'un cookie en gérant automatique le prefix par défaut n'aurait plus aucun sens. De même, si je devais passer en argument des dizaines de variables en arguments à certaines fonctions, je ne m'en sortirai jamais !

Ma dernière idée : utiliser les constantes. J'ai vu que beaucoup de systèmes, comme xoop, utilisent cette méthode pour leur variables de configuration, ou leurs variables "langages".

Qu'en pensez vous ?
Que pouvez vous me conseiller ?

[CrazyCat]

chacun ses gouts, pour ma part je préfère un tableau de variables, ce qui me permet de n'avoir qu'une variable appelée et que je peux moduler.

Par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
$config['db']['host'] = "localhost";
$config['db']['base'] = "mabase";
$config['db']['user'] = "root";
$config['db']['pass'] = "";
 
$config['path']['real'] = "/home/crazicat/www/";
$config['path']['images'] = "/images";
...

Et je peux soit appeler $config, soit $config['base'] soit $config['path'], ...
Bref, je me fais ma variable globale à moi

[Malikak]

Oui, mais tu ne peux pas l'utiliser à l'interieur des fonctions... sauf si tu la passes en argument à chaque fois, mais c'est pas pratique... ou si tu la passes en global, mais beaucoup le déconseillent...

[Maxoo]

tu laisses ça dans une page .php et tu l'inclus quand tu en as besoin.

[Malikak]

J'ai l'impression que ma question n'est pas clair... elle porte avant tout sur la portée des variables :

Une variable $config, c'est bien, mais ce n'est valable qu'en locale, donc ce n'est pas utilisable à l'interieur des fonctions, ni même à l'interieur des objets. Et appeller cette page dans chaque fonction, et ce à chaque appel de la-dite fonction, est plutot inconcevable.

[Eric Berger]

Une variable $config, c'est bien, mais ce n'est valable qu'en locale, donc ce n'est pas utilisable à l'interieur des fonctions, ni même à l'interieur des objets. Et appeller cette page dans chaque fonction, et ce à chaque appel de la-dite fonction, est plutot inconcevable.

Si la variable $config (ou ta liste de variables) est définie a l'extérieur d'une fonction ou d'une classe, sa portée sera globale et tu pourras l'utiliser depuis une fonction sans la passer en argument.

Je te conseille d'aller jeter un oeil directement sur la doc officielle, c'est très bien expliqué
http://www.php.net/manual/fr/languag...bles.scope.php

[ska_root]

Salut,

tu peux aussi rendre globale la portée de tes variables en les déclarant à l'aide de la fonction define() ce qui fait de cette variable une constante.

Mais c'est la même chose que les autres, il faut inclure un fichier de setup dans la page. Je ne suis pas sûr que tu aies bien compris que l'inclusion peut être faite avant tout appel à une classe ou une fonction.

Tous comme les superglobals, les constantes sont accessibles de manière globale. Vous pouvez la définir n'importe où, et y accéder depuis n'importe quelle fonction.

[Malikak]

Je pense que vous n'avez pas compris le sens de ma question. Ou que vous n'avez pas du tout compris mon message initiale.

Vous me parlez de "variables globales" ou de "constante", alors que c'est justement les solutions que j'ai proposé en introduction :

Une idée serait de les définir en global, et d'y accéder ensuite par le tableau $_GLOBALS, mais d'après ce qu'on m'a dit ici, des variables globales n'avaient pas beaucoup de sens dans des fonctions, et encore moins dans des objets.

Ma dernière idée : utiliser les constantes.

Or ma question était justement : quelle est, par retour d'expérience et selon vous, la méthode la plus judicieuse ? Vu qu'apparament, selon beaucoup de personnes expérimentées, utiliser les "globales" dans les fonctions est très déconseillé.

Je repose ma question :
1. Utiliser une variable globale peut être une bonne alternative ici, en tant "qu'exception à la règle".
2. Définir un tas de constantes ne peut-il pas nuire aux peformances ?

[ePoX]

Une idée serait de les définir en global, et d'y accéder ensuite par le tableau $_GLOBALS, mais d'après ce qu'on m'a dit ici, des variables globales n'avaient pas beaucoup de sens dans des fonctions, et encore moins dans des objets.

Certes ce n'est pas super propre, mais comme tu l'à fait remarquer en procédurale il y à assez peu de solution.
Pour ma part en procedurale se sont des constantes, comme le dit ska. En objet, pourquoi ne pas passer par une classe spécifique avec des attributs static.

De toute façon l'un dans l'autre sa se ressemble, la seconde solution apporte juste un peu plus de cohérence, mais c'est tout.

[Eric Berger]

1. Utiliser une variable globale peut être une bonne alternative ici, en tant "qu'exception à la règle".

Oui, je pense que c'est ce qui se pratique le plus dans ce genre de contexte, je ne parlerais même pas d'exception à la règle.

2. Définir un tas de constantes ne peut-il pas nuire aux peformances ?

Non, franchement je ne pense pas... reste à définir "un tas" mais si il ne s'agit pas de milliers de constante, le temps de chargement est insignifiant.

[Malikak]

Désolé pour le retard.

De toute façon l'un dans l'autre sa se ressemble, la seconde solution apporte juste un peu plus de cohérence, mais c'est tout.

En quoi cela apporte plus de cohérence ?
Je trouve ça plus dur à gérer, justement, si toutes les variables de configurations ne sont pas dans un même fichier (par exemple, inutile de charger la configuration du forum sur le blog, et inversement... mais certains variables sont communes aux deux.)

[drommk]

pour moi : constantes

[Eric Berger]

En quoi cela apporte plus de cohérence ?
Je trouve ça plus dur à gérer, justement, si toutes les variables de configurations ne sont pas dans un même fichier (par exemple, inutile de charger la configuration du forum sur le blog, et inversement... mais certains variables sont communes aux deux.)

Il faut tenir compte du coût que ça représente (quantité de travail) et de charger quelques dizaines de paramètres a un coût insignifiant. On donnera par exemple plus d'importance à choisir quelles requêtes SQL sont nécessaires car elles sont plus gourmandes en ressources. Pourtant, pour charger une page du forum de developpez, le serveur fera plusieurs dizaines de requêtes et le chargement n'est pas lent pour autant, même avec plusieurs centaine d'utilisateurs simultanés.

Toute cette explication pour que tu relativise un peu le problème de performances lié au chargement de quelques variables.

Conclusion: choisis ce qui est le plus pratique pour toi, sans te demander si c'est la solution la plus performante.

[ePoX]

Citation:
ePoX a écrit :
De toute façon l'un dans l'autre sa se ressemble, la seconde solution apporte juste un peu plus de cohérence, mais c'est tout.



En quoi cela apporte plus de cohérence ?
Je trouve ça plus dur à gérer, justement, si toutes les variables de configurations ne sont pas dans un même fichier (par exemple, inutile de charger la configuration du forum sur le blog, et inversement... mais certains variables sont communes aux deux.)

Dans un projet fait entièrement en objet utilisé une classe avec des attributs static est plus cohérent dans l'écriture car tu passes tout le temps par des classes, et non pas des valeurs défini hors des classes comme les constantes défini avec la focntion define().

Encore une fois l'un dans l'autre c'est pareil au final, c'est juste deux manière différentes de produire le même résultat, l'une porte plutot la marque d'un code procédural, et l'autre la marque d'un code objet.

[wamania]

je serais plus pour une classe "statique" style singleton.
dans chaque fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$config = CMyConfig::getConfig();
 
avec 
class CMyConfig
{
    private $tab_config;
 
    static function getConfig()
    {
        si $tab_config existe, return $tab_config
        sinon $this->createConfig() et return $tab_config;
    }
 
    private function createConfig()
    {
        charge tes configs dans $tab_config;
    }
}

ceci dit, j'utilise aussi des globals, et ça me gène pas vraiment. Tout dépend du besoin de "propreté"

[Malikak]

Ben merci à tous pour réponses