Discussion :

[sql_ignorant]

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 :

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

1
2
3
<config>
	<include name="main" value="$_SERVER['DOCUMENT_ROOT']" />
</config>

Ensuite dans mon php, j'ecrit ceci :

Code :

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

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 :

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

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 ?

[andry.aime]

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

[RunCodePhp]

Salut

Code :

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

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 :

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

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) ?

[sql_ignorant]

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 :

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

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`.

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 :

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

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.

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.

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.

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 !

[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
...
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 :

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

dirname(dirname(__FILE__))

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 :

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

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.

[sql_ignorant]

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 :

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

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.

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.

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 :

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

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...