Discussion :

[Aizen64]

Bonjour,

j'ai une question assez basique mais importante, ma couche d'accès aux données fonctionne correctement, le seul problème étant que les URLs d'appels à mes services web ou base de données sont différents ainsi que mes logins/mot de passe selon que mon code fonctionne en environnement de développement ou en production.

Qu'elle est la meilleure approche, je parle réellement de structure de code, en réalité ce conseil n'est pas lié fortement à PHP.

Passer en paramètre de la couche data les données qui changent selon l’environnement ? En d'autres termes, dans le constructeur.

[tdutrion]

Bonjour,

Si tu regardes du côté des frameworks, en général on passe effectivement ces variables dans les constructeurs car elles sont nécessaires à la création de l'objet. Plus spécifiquement, les frameworks utilisent des factories pour créer ces objets en injectant la configuration.

Exemple avec Zend Framework

Niveau configuration, sur ZF2 par exemple on utilise en général des fichiers .local.php pour overrider les .global.php et mettre ces settings spécifiques. Une autre variante consiste à utiliser des variables d'environnement, et ça se prête particulièrement bien au déploiements avec Docker ou sur des PAAS type Heroku. Pour cette dernière solution je te conseille d'utiliser dotEnv qui est une très bonne librairie.

Personnellement j'ai tendance à utiliser ZF et ajouter dotEnv, récupérant ensuite les variables d'environnement dans le .global.php, mais gardant la possibilité d'écraser tout ça avec un .local pour un environnement vraiment plus spécifique (lors d'un test durant lequel tu changes les adresses de ton object storage, si tu en as un cher pour staging/prod par exemple et un vraiment pas cher pour la dev...).

Si tu m'en dis plus sur ton setup, je pourrais t'aider mieux je pense.

[Aizen64]

Merci pour ta réponse. J'aurais du le préciser au départ, PHP brut, pas de framework.

[tdutrion]

Je prends les frameworks en exemple car ils apportent des bonnes pratiques mais ce ne sont que des exemples...

Comment gères-tu la configuration ? As-tu un point d'accès unique à ton application ? Utilises-tu un service manager ?

[Aizen64]

Je prends les frameworks en exemple car ils apportent des bonnes pratiques mais ce ne sont que des exemples...

Comment gères-tu la configuration ? As-tu un point d'accès unique à ton application ? Utilises-tu un service manager ?

Jamais utilisé de service manager, pour l'instant l'exécute mes pages manuellement en ligne de commande via : php monscript.php ce qui passe pour faire des tests, par contre :
- si j'utilise les variables d'environnement d'Apache (via $_ENV ?), je devrais faire tourner mes scripts via le navigateur et non via le terminal sinon je n'aurai pas accès aux variables en question.

Cette approche me parait être une bonne idée, d'autres points pour me guider ?

[tdutrion]

Avec DotEnv tu peux de toutes façons mettre les variables en clé=valeur dans le fichier .env

Plutôt que $_ENV on va plutôt utiliser getenv qui ne vérifie pas la casse de ta variable.

Sinon, les variables d'environnements peuvent être mises sur le système directement, pas uniquement dans Apache. Quel OS utilises-tu ? Niveau système je trouves personnellement que les variables d'environnement ne sont pas pratiques à mettre en place, et avec plusieurs projets et environnement ça part vite en cacahuète... du coup le mieux c'est d'utiliser les .env sur les environnements locaux, puis les variables d'environnement sur les déploiments, ou d'utiliser de la virtualisation (puphpet), du Docker ou autre, voir des PAAS (Openshift gratuit pour 3 small engine par exemple, Pagodabox gratuit en version de test)

[Aizen64]

Avec DotEnv tu peux de toutes façons mettre les variables en clé=valeur dans le fichier .env

Plutôt que $_ENV on va plutôt utiliser getenv qui ne vérifie pas la casse de ta variable.

Sinon, les variables d'environnements peuvent être mises sur le système directement, pas uniquement dans Apache. Quel OS utilises-tu ? Niveau système je trouves personnellement que les variables d'environnement ne sont pas pratiques à mettre en place, et avec plusieurs projets et environnement ça part vite en cacahuète... du coup le mieux c'est d'utiliser les .env sur les environnements locaux, puis les variables d'environnement sur les déploiments, ou d'utiliser de la virtualisation (puphpet), du Docker ou autre, voir des PAAS (Openshift gratuit pour 3 small engine par exemple, Pagodabox gratuit en version de test)

Merci pour ces infos.

Pour répondre à ta question, le serveur tourne sur : Debian 8.1

Après un bref débat, je dois mettre ces données dans un fichier à part à l'extérieur du code de mon projet principal à inclure ensuite dans mon projet. Par principe, pourquoi pas ? Dans les faits, ça ne fonctionne pas. Bien que je pense en comprendre la raison, je ne sais pas comment le résoudre, explications :

J'ai un fichier de conf. à part qui contient :

Code :

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

1
2
3
4
5
6
 
<?php
 
URL = "http://mon_url_de_dev.com"
 
UTILISATEUR = ["utilisateur" => "moi", "motdepasse" => "monmotdepasse"];

Si je fais un require_once("mon_fichier_avec_variables.php") dans un de mes scripts qui en a besoin, les constantes (ou variables) définies dans le fichier de conf. ne sont pas définies à l"exécution, ce qui me parait logique sachant que les constantes/variables n'ont qu'une portée dans le fichier PHP dans lequel elles sont stockées. Après le require, ces données n'existent plus.

Ma logique est-elle bonne et comment contourner le problème ? Je vais faire en sorte de trouver la solution mais il me parait important de poser la question. C'est pas par fainéantise que je le fais.

EDIT :
J'ai oublié de préciser, le code exécuté est une méthode à l'intérieur d'une classe, le require_once est situé en début de fichier, et les données qui y sont déclarés ne sont pas visibles par la classe ce qui, je pense, explique le message de variables non définies. Mon problème reste intact. J'ai jeté un œil sur use ici mais si je fais :

Code :

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

1
2
 
use const \dossier\sous_dossier\mon_fichier.php\MA_CONSTANTE;

Hé bien ça ne fonctionne pas, ce qui ne m'étonne pas, la syntaxe me parait bien étrange.

[tdutrion]

Alors d'après le code donné, ça ne marchera forcément pas, car le code est loin d'être valide : 3v4l.

Il faut donc commencer par résoudre ce problème là.

Comme tu as un tableau, pas de variables d'environnement... Ou alors tu splittes le tableau en variable :

Code :

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

1
2
3
4
 
URL=http://mon_url_de_dev.com 
UTILISATEUR_ID=moi
UTILISATEUR_MOTDEPASSE=monmotdepasse

Là j'improvise depuis le code que tu donnes, mais il vaut mieux écrire des noms plus sensés (notamment MOT_DE_PASSE plutot que MOTDEPASSE, PASSWORD encore mieux car un seul mot).

Ensuite, tu peux alors utiliser dotEnv et soit passer to fichier en paramètres du constructeur, soit faire un lien symbolique de ton fichier de conf vers .env à la racine de ton projet et charger ce lien comme étant le fichier de conf.

Sinon, dans le cas où tu esperais avoir des constantes dans ton fichier de config (et donc où tu aurais utilisé const ou define pour le tableau), tu devrais les appeler sans aucun namespace car le fichier les contenant n'est pas namespacé.

Où as-tu trouvé les syntaxes dont tu parles dans ton message ?

[Aizen64]

Je vais tester ce que tu m'as dit, au premier abord, j'ai du mal à remettre les choses en place mais ça devrait aller.

Pour ma syntaxe, regarde mon précédent message à "ici", c'est un lien.

[tdutrion]

Je vois bien le lien, mais rien ne ressemblant à ce que tu codes à l'intérieur...

Je vois par contre en effet l'import d'une constante déclarée dans un namespace, mais namespace != file path, donc pas de .php par exemple.

[Aizen64]

Je vois bien le lien, mais rien ne ressemblant à ce que tu codes à l'intérieur...

Je vois par contre en effet l'import d'une constante déclarée dans un namespace, mais namespace != file path, donc pas de .php par exemple.

Sauf qu'en l'occurrence, le fichier contenant les constantes est en dehors du dossier dans lequel est stocké mon projet, par conséquent, je ne vois pas comment y faire référence en tant que namespace dans ledit projet.

[tdutrion]

L'emplacement du fichier ne détermine pas son namespace, seul l'instruction namespace le fait. En l'occurence il n'y a pas de namespace dans ton cas.

Un namespace est juste une syntaxe pour en quelque sorte séparer en modules. Ensuite, les PSRs (1 et 4 notamment) recommandent une certaine convention de nommage qui permet d'autoloader les fichiers. Personnellement je suis ces recommandations, mais libre à toi (ou aux contraintes imposées) de changer la structure, c'est juste que tu ne profiteras pas de ces autoload bien faits.

[Aizen64]

J'ai finalement trouvé une solution au problème. De mon humble avis, la solution ressemble plus à de la cuisine qu'autre chose, la solution :

1. création en dehors de mon dossier de projet d'une classe qui contient les données spécifiques à l'environnement donné. je l'ai nommé Env (Env.php),
2. Cette classe contient 3 variables statiques : $url, $username, $password initialisées aux valeurs de l'environnement dans lequel elles sont utilisées,
3. Ajout dans ma couche d'accès aux données d'un require_once() relatif vers Env.php,
4. Appel des variables statiques via l'opérateur :: d'espace de noms, ce qui donne :

Code :

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

1
2
3
4
 
Env::$username;
Env::$password;
Env::$url;

Un feedback ? Des améliorations possibles ? Une critique ? Avec plaisir si je peux m'améliorer.