Forcer l'interprétation d'une variable stockée dans une string

Version imprimable

Bonsoir,

J'aimerai stocker dans un fichier xml la configuration de mon application web, et notamment les require_once(...). J'ai donc un fichier xml du genre :
Code:

1 2 3 <config> <include name="main" value="$_SERVER['DOCUMENT_ROOT']" /> </config>
Ensuite dans mon php, j'ecrit ceci :
Code:

1 2 3 4 5 <?php require_once($_SERVER['DOCUMENT_ROOT'] . "/config/Config.inc"); // Le seul require_once() "en dur" $includes = Config::getInstance()->getIncludes(); // Singleton qui parse le fichier xml et retourne un tableau du genre main => $_SERVER['DOCUMENT_ROOT'] require_once($includes["main"] . '/essai.inc'); ?>
Le problème est que lors du runtime, l'interpréteur n'arrive pas à inclure le fichier $_SERVER['DOCUMENT_ROOT']/essai.inc parce que la variable $_SERVER['DOCUMENT_ROOT'] n'est pas interprétée.

J'ai donc le retour :
Code:

1 2 Warning: require_once($_SERVER['DOCUMENT_ROOT']/essai.inc) [function.require-once]: failed to open stream: No such file or directory in /var/www/server/index.php on line 4
Connaissez vous une solution à ce genre de problème ?

30/03/2010, 07h49
andry.aime

Bonjour,
Passes la fonction dans un String avec lequel tu faits un eval.
30/03/2010, 08h48
RunCodePhp
Salut

Code:

require_once($_SERVER['DOCUMENT_ROOT'] . "/config/Config.inc");

Il y a tout de même un truc que je ne comprends pas.
Le chemin physique, le (DOCUMENT_ROOT) est déjà connu puisque que c'est grâce à lui que tu parvient a inclure "Config.inc", la classe Config.
A quoi bon avoir cette info (la même) dans le xml ?

Ton code revient à faire ceci théoriquement :
Code:

1 2 3 require_once($_SERVER['DOCUMENT_ROOT'] . "/config/Config.inc"); require_once($_SERVER['DOCUMENT_ROOT'] . '/essai.inc');
De plus, théoriquement il ne faudrait pas mettre du Php dans le xml, mais la chaine que contient $_SERVER['DOCUMENT_ROOT'], c'est donc au moment où il est créé le xml où ça doit être fait, quitte à le mettre "en dur" si le xml n'est pas créer dynamiquement.

Aussi, s'il y a des chemins, des configs différentes selon tel ou tel conditions, alors il faudrait que le xml propose les différentes alternatives.
Le parseur devra alors récupérer les bonnes configs selon le cas, en faisant une requête dans le xml.

Si le xml ne propose pas au moins 2 alternatives, on peu dire qu'il ne sert finalement pas à grand chose, autant créer directement un fichier Php avec les configs. Soit des variables, ou des tableaux, ou encore des constantes.

Enfin, c'est ce qu'il me semble sur ce point là.

Petit truc en passant.
Pour inclure simplement des fichiers, utiliser les fonctions set_include_path() et get_include_path() pour définir un ou 2 chemins clés me semble une bonne technique.

Un petite question comme ça.
Le truc que tu essai de faire (des configs dans un xml), ne serait il pas pour différencier des chemins en local et distant (par hasard) ?
30/03/2010, 20h53
sql_ignorant
Citation:

Envoyé par andry.aime

Passes la fonction dans un String avec lequel tu faits un eval.

J'ai probablement mal compris ce que tu disais (notamment "Passes la fonction dans un String") mais eval semble m'obliger à écrire :
Code:

1 2 3 <config> <include name="main" value="return $_SERVER['DOCUMENT_ROOT'];" /> </config>
et dans ce cas, je trouve ça vraiment pas propre. J'imaginais une solution du genre anti-simple-quote de bash `$var`.

Citation:

Envoyé par RunCodePhp

Le chemin physique, le (DOCUMENT_ROOT) est déjà connu puisque que c'est grâce à lui que tu parvient a inclure "Config.inc", la classe Config.

Justement non, c'est la raison pour laquelle j'inclus la classe Config avec la ligne

Code:

require_once($_SERVER['DOCUMENT_ROOT'] . "/config/Config.inc");

pour ne pas avoir à connaitre le DOCUMENT_ROOT.
A l'heure actuelle, l'application se trouve sur un serveur de dev ; le but est donc d'avoir le moins de fichier à modifier lors du déploiment sur le serveur de prod, d'où l'utilisation de la variable $_SERVER['DOCUMENT_ROOT'] pour trouver la classe Config car c'est le seul include qui n'est pas configurable.

Citation:

Envoyé par RunCodePhp

De plus, théoriquement il ne faudrait pas mettre du Php dans le xml, mais la chaîne que contient $_SERVER['DOCUMENT_ROOT'], c'est donc au moment où il est créé le xml où ça doit être fait, quitte à le mettre "en dur" si le xml n'est pas créer dynamiquement.

Oui, je souhaitais faire ça par flemme car cela me faisais une configuration de moins à faire et que le fichier de conf est écrit "en dur" ; mais en fait, plus j'y pense, plus je me dis que tu as raison. La nuit porte conseil, mais il me semble de plus en plus évident qu'il ne faut pas faire ça.

Citation:

Envoyé par RunCodePhp

Pour inclure simplement des fichiers, utiliser les fonctions set_include_path() et get_include_path() pour définir un ou 2 chemins clés me semble une bonne technique.

Dans ma vie professionnelle, je me suis occupé entre autres de dev en C et maintenant de dev en Java, donc je suis pas très fan d'include global, je préfère des includes ou des imports locaux. Probablement parce que je n'y vois pas une utilité réelle.

Citation:

Envoyé par RunCodePhp

Le truc que tu essai de faire (des configs dans un xml), ne serait il pas pour différencier des chemins en local et distant (par hasard) ?

Oui, c'est exactement ça ; j'ai des classes communes à d'autres futurs projets qui ne sont pas sur le serveur frontal (typiquement SqlException) ; vive l'auto-hébergement et surtout vivement le ftth synchrone !

Citation:

Envoyé par RunCodePhp

Le chemin physique, le (DOCUMENT_ROOT) est déjà connu puisque que c'est grâce à lui que tu parvient a inclure "Config.inc", la classe Config.

Citation:

Envoyé par sql_ignorant

Justement non, c'est la raison pour laquelle j'inclus la classe Config avec la ligne
...
pour ne pas avoir à connaitre le DOCUMENT_ROOT.
A l'heure actuelle, l'application se trouve sur un serveur de dev ; le but est donc d'avoir le moins de fichier à modifier lors du déploiment sur le serveur de prod, d'où l'utilisation de la variable $_SERVER['DOCUMENT_ROOT'] pour trouver la classe Config car c'est le seul include qui n'est pas configurable.

On ne se comprend pas, je pense.

Faut être clair, ta classe Config est certes le seule, je dirais plutôt le 1er include() qui n'est pas configurable, d'accord, mais pour pouvoir l'inclure, il te faut avant tout un chemin. Il faut que Php sache où la chercher, du moins son fichier.

Le fait d'utiliser $_SERVER['DOCUMENT_ROOT'] pour l'inclure, veut dire que tu connais son chemin, sinon tu ne l'utiliserais pas.
Après, que tu veuille stocker ce chemin dans une autre config, autre que $_SERVER['DOCUMENT_ROOT'] (pour des raisons pratiques), pourquoi pas, mais de toute manière, le chemin physique est connu, peut être obtenu, dès la 1ère ligne de code, quelque soit le fichier (php).
Tu peux donc initialiser ta config avant même inclure la classe, c'est une certitude.

Il n'y a donc pas lieu de vouloir tenter de ré-interpréter une donnée connue d'avance.

Petite parenthèse.
La donnée retournée par $_SERVER['DOCUMENT'] n'est pas obligatoirement une données fiable, le chemin physique peut être faut, pas le bon.
Un code comme celui ci est théoriquement plus fiable :

Code:

dirname(dirname(__FILE__))

Citation:

Dans ma vie professionnelle, je me suis occupé entre autres de dev en C et maintenant de dev en Java, donc je suis pas très fan d'include global, je préfère des includes ou des imports locaux. Probablement parce que je n'y vois pas une utilité réelle.

Peut ête, mais si on espionne un peu comment les autre font, comme ZendFrameWork, CakePhp (pour ne citer que 2 FrameWork connus), ils les utilisent.
Ce sont tout de même des références.
Aussi, il ne faudrait pas confondre ces configs avec les chemins qu'on peu définir dans l'environnement du système (variables d'environnement sur Windows par exemple), ça n'a rien avoir.

Ce seront des chemins globaux, certes, mais si on n'abuse pas, et qu'on se contente de définir le chemin physique, et éventuellement un 2ème (pour une bibliothèque Pear, ou la sienne par exemple), c'est fort pratique, crois moi ;)

Enfin bref ... tout ça pour dire qu'à mon sens tu tente de définir quelque chose de connu.
Faire comme ceci reviendrait au même
Code:

1 2 3 4 5 6 <?php require_once($_SERVER['DOCUMENT_ROOT'] . "/config/Config.inc"); // Le seul require_once() "en dur" $includes = Config::getInstance()->getIncludes(); $includes['main'] = $_SERVER['DOCUMENT_ROOT']; require_once($includes['main'] . '/essai.inc'); ?>
Ce qui fait que tu peux te passer du noeud "main" qui se trouve dans le xml.

Citation:

Envoyé par RunCodePhp

La donnée retournée par $_SERVER['DOCUMENT'] n'est pas obligatoirement une données fiable, le chemin physique peut être faut, pas le bon.
Un code comme celui ci est théoriquement plus fiable :

Code:

dirname(dirname(__FILE__))

Théoriquement, peut-être, mais dans les faits, je ne pense pas. En effet, n'ayant pas encore testé cette ligne de code mais en considérant la commande basename linux, ce code va retourner le chemin en dur du fichier, par exemple /var/www/mon_site_web/mon_fichier.inc ; hors cela ne gère donc pas les hôtes virtuels apache, ce n'est donc vraiment pas fiable du tout ! Ne sachant pas si je pourrais m'auto-hébergé ou pas, en fonction du nombre de connexion et donc de mon débit montant, je me trouve dans l'obligation de prendre ce paramètre en compte (on peut toujours rêver ;)). Ma rue est fibrée, certes, mais uniquement pour l'opérateur marchand-de-fruit. Et un serveur dédié chez les hébergeurs coûte bonbon, c'est donc une donnée non négligeable lors de la conception.

Citation:

Envoyé par RunCodePhp

Peut ête, mais si on espionne un peu comment les autre font, comme ZendFrameWork, CakePhp (pour ne citer que 2 FrameWork connus), ils les utilisent.
Ce sont tout de même des références.
Aussi, il ne faudrait pas confondre ces configs avec les chemins qu'on peu définir dans l'environnement du système (variables d'environnement sur Windows par exemple), ça n'a rien avoir.

Ce seront des chemins globaux, certes, mais si on n'abuse pas, et qu'on se contente de définir le chemin physique, et éventuellement un 2ème (pour une bibliothèque Pear, ou la sienne par exemple), c'est fort pratique, crois moi ;)

Bien sûr que ton raisonnement est logique ; simplement, je n'ai pas encore pris le temps de prende cela en considération. Mais ayant une vie pro déjà bien remplie et une vie perso bien remplie également, cela m'oblige à m'occuper de mes projets maison que quand tout mon petit monde est couché ; c'est bien la raison pour laquelle tout cela avance lentement. Je prendrais donc le temps de réchéchir à ta proposition. Mais il faut prendre en considération la suite de mon post.
Citation:
Envoyé par RunCodePhp
On ne se comprend pas, je pense.

Faut être clair, ta classe Config est certes le seule, je dirais plutôt le 1er include() qui n'est pas configurable, d'accord, mais pour pouvoir l'inclure, il te faut avant tout un chemin. Il faut que Php sache où la chercher, du moins son fichier.

Le fait d'utiliser $_SERVER['DOCUMENT_ROOT'] pour l'inclure, veut dire que tu connais son chemin, sinon tu ne l'utiliserais pas.
Après, que tu veuille stocker ce chemin dans une autre config, autre que $_SERVER['DOCUMENT_ROOT'] (pour des raisons pratiques), pourquoi pas, mais de toute manière, le chemin physique est connu, peut être obtenu, dès la 1ère ligne de code, quelque soit le fichier (php).
Tu peux donc initialiser ta config avant même inclure la classe, c'est une certitude.

Il n'y a donc pas lieu de vouloir tenter de ré-interpréter une donnée connue d'avance.

[...]

Enfin bref ... tout ça pour dire qu'à mon sens tu tente de définir quelque chose de connu.
Faire comme ceci reviendrait au même
Code:

1 2 3 4 5 6 <?php require_once($_SERVER['DOCUMENT_ROOT'] . "/config/Config.inc"); // Le seul require_once() "en dur" $includes = Config::getInstance()->getIncludes(); $includes['main'] = $_SERVER['DOCUMENT_ROOT']; require_once($includes['main'] . '/essai.inc'); ?>
Ce qui fait que tu peux te passer du noeud "main" qui se trouve dans le xml.
Non. Parce que je ne souhaite pas exclure la possibilité que seuls les scripts php frontaux se trouvent sur le serveur frontal ! Ainsi, les classes *.inc (sauf Config.inc) pourraient se trouver sur un serveur local. Je souhaite rendre mon appli la plus souple possible, quitte à dupliquer certaines variables...

Surtout pas un eval, il te suffit de faire ca:
Code:

1 2 3 4 5 6 <?php require_once($_SERVER['DOCUMENT_ROOT'] . "/config/Config.inc"); // Le seul require_once() "en dur" $includes = Config::getInstance()->getIncludes(); // Singleton qui parse le fichier xml et retourne un tableau du genre main => $_SERVER['DOCUMENT_ROOT'] require_once($$includes["main"] . '/essai.inc'); ?>
Remarquer le double $$

Je dois surement être dans l'erreur, car ca ferait beaucoup de texte pour une solution d'un caractère...

01/04/2010, 07h50
RunCodePhp

Citation:

Théoriquement, peut-être, mais dans les faits, je ne pense pas. En effet, n'ayant pas encore testé cette ligne de code mais en considérant la commande basename linux, ce code va retourner le chemin en dur du fichier, par exemple /var/www/mon_site_web/mon_fichier.inc ; hors cela ne gère donc pas les hôtes virtuels apache, ce n'est donc vraiment pas fiable du tout !

Tu as des préjugés, tu ne teste pas, c'est étonnant tout de même.

C'est l'inverse, un $_SERVER['DOCUMENT_ROOT'] dans certain cas ne retournera pas le chemin de l'hôte virtuel justement.
Tu n'as pas encore rencontré le cas, du coup, tu te fais une idée fausse.

Je peux te l'affirmer car de mon coté mon projet est installé sur un Wind Xp, et sur un Xubutu, les 2 en local pour des essais, et développement.
Sur Wind XP, le $_SERVER['DOCUMENT_ROOT'] retourne le bon chemin.
Par contre, sur Xubutu, non !!!
Toute une histoire du fait que Apache/Php est installé dans ROOT, et que l'espace virtuel lui se trouve dans un "utilisateur" (home/utilisateur/public_html/...). Tout ça pour une histoire de droit sur les fichiers.
Le fait de ne pas avoir redéfini le chemin dans Apache du DOCUMENT_ROOT fait que si je l'exploite, il me retourne le chemin ROOT !!!

Pour obtenir un chemin fiable, seul le code que je t'ai donné fonctionne.
Soit dit en passant, les FrameWork ZendFrameWork et CakePhp utilisent ce même code, et pas $_SERVER['DOCUMENT_ROOT'], ce n'est pas un hasard, ce n'est pas pour rien.

En tout cas, tu oubli que tout ce qui vient du $_SERVER est défini dans le httpd.conf (ou autre alias), donc Apache, et non du système. L'administrateur fait donc ce qu'il veut.
Les données peuvent ne pas être celles que l'on attend.

Citation:

Non. Parce que je ne souhaite pas exclure la possibilité que seuls les scripts php frontaux se trouvent sur le serveur frontal ! Ainsi, les classes *.inc (sauf Config.inc) pourraient se trouver sur un serveur local. Je souhaite rendre mon appli la plus souple possible, quitte à dupliquer certaines variables...

2 choses une (il n'y en a pas 36) :
1/ Soit ta classe et tes script frontaux peuvent être basés du $_SERVER['DOCUMET_ROOT'], du coup il est inutile de le mettre dans le XML car ta config tu peux la créer tout de suite (le code que j'ai mis).
Il est inutile de ré-interpréter un code Php dans un XML alors que tu l'a sous la main, c'est limite absurde.

2/ Soit tes script ne peuvent pas être basés du $_SERVER['DOCUMENT_ROOT'] (pas situés au même endroit). Du coup, il va falloir le définir "en dur" dans le XML si aucune fonction Php ne peu le retourner (au même titre que les autres configs).

A mon avis, on a à quelque chose près adopté le même principe.
Un fichier XML avec des config (des chemins, celle de la Bdd, etc ...)
Une classe Config qui parse le XML pour générer des config Php (de mon coté c'est des constantes).
Cependant, j'ai mis les chemins "en dur" dans le XML, sans exception.
100% du code de l'appli repose sur ces config.

Donc j'ai comme toi dans le XML un "main" (il ne porte pas le même nom, mais c'est la même chose), mais, il est mis "en dur".
Je suis parti du principe que, une fois le projet installé, cette config ne va pas changée tous les 4 matins.
C'est la même chose pour les config de la BDD (hote, user, pass), etc ....
Donc il me semble inutile de récupérer sans cesse un chemin que l'on peu obtenir soit chez soit (en local) où de son hébergeur.

Tu pourrais donc le mettre "en dur", au même titre que tes autres config, car une de plus ou une de moins, si on réfléchi, ça ne prend pas des plombes.

Citation:
Envoyé par FMaz
Surtout pas un eval, il te suffit de faire ca:
Code:

1 2 3 4 5 6 <?php require_once($_SERVER['DOCUMENT_ROOT'] . "/config/Config.inc"); // Le seul require_once() "en dur" $includes = Config::getInstance()->getIncludes(); // Singleton qui parse le fichier xml et retourne un tableau du genre main => $_SERVER['DOCUMENT_ROOT'] require_once($$includes["main"] . '/essai.inc'); ?>
Remarquer le double $$

Je dois surement être dans l'erreur, car ca ferait beaucoup de texte pour une solution d'un caractère...
Non, tu n'es pas dans l'erreur, mais malheureusement, cela ne fonctionne pas non plus, cela me retourne cette erreur :

Code:

Notice: Undefined variable: $_SERVER['DOCUMENT_ROOT']

J'ai réalisé quelques tests genre :
Code:

1 2 3 $toto = "$titi"; $titi = "bonjour le monde"; echo $$toto;
ce qui retourne :
Code:

1 2 Notice: Undefined variable: titi in ... Notice: Undefined variable: in ...
ou :
Code:

1 2 3 $toto = "\$titi"; $titi = "bonjour le monde"; echo $$toto;
et qui retourne :

Code:

Notice: Undefined variable: $titi

mais ce n'est pas grave car, avec du recul, le titre de mon poste est trop vague. Merci malgré tout de ton aide.

Citation:

Envoyé par RunCodePhp

Tu as des préjugés, tu ne teste pas, c'est étonnant tout de même.

C'est l'inverse, un $_SERVER['DOCUMENT_ROOT'] dans certain cas ne retournera pas le chemin de l'hôte virtuel justement.
Tu n'as pas encore rencontré le cas, du coup, tu te fais une idée fausse.

Oui, tu as raison, dirname(...) fonctionne bien avec les hôtes virtuels. Même si je ne suis pas fan du dirname(dirname(...)), cette solution semble effectivement la meilleure. J'ai désormais besoin d'avoir du recul par rapport à ça et réfléchir à mes besoins globaux. Merci pour ton expérience et ton savoir.

06/04/2010, 23h15
FMaz
Citation:
Code:

1 2 3 4 $toto = "\$titi"; $titi = "bonjour le monde"; echo $$toto;

et qui retourne :

Code:

1 2 Notice: Undefined variable: $titi
Non mais minute, il faut réfléchir un peu quand même:
echo $$toto;
echo ${$toto}; //Équivalent de, on évalue $toto
echo ${'$titi'}; //On évalue tout le contenu de l'accolade:

La variable nommé $titi est innexistante. Normal, quel genre de variable contiendrait un $ dans son nom ? :p

Si tu veux tester, essaie:
Code:

1 2 3 4 $toto = "titi"; $titi = "bonjour le monde"; echo $$toto;
07/04/2010, 21h14
sql_ignorant
Citation:
Envoyé par FMaz

Non mais minute, il faut réfléchir un peu quand même:
echo $$toto;
echo ${$toto}; //Équivalent de, on évalue $toto
echo ${'$titi'}; //On évalue tout le contenu de l'accolade:

La variable nommé $titi est innexistante. Normal, quel genre de variable contiendrait un $ dans son nom ? :p

Si tu veux tester, essaie:

Code:

1 2 3 4 $toto = "titi"; $titi = "bonjour le monde"; echo $$toto;
Ma demande était mauvaise, il est vrai qu'il ne vaut mieux pas mettre du php dans un fichier de config xml donc cette solution ne me convient pas finalement.

Mais oui, ta proposition fonctionne, ce qui me permet de tagger en résolu cette discution pour ceux qui auront besoin de ce genre de bidouille en lisant le titre.

Merci à vous tous pour votre aide