Où mettre les données constantes ?

[phenix]

Heu, et pourquoi pas les session ? sa me semble indiqué dans ce cas si.

[Argorate]

Ca dépend se qu'on veut stocker, mais une session c'est pour stocker des données lié a la session... (si si j'vous jure! :p)
Donc, si c'est quelque chose de global/commun a tous, ça ne me semble pas judicieux de la mettre là. ^^

Pour l’ini, je n’ai jamais essayé, mais je me demande si ce serait plus rapide, car il y a forcément un traitement à faire pour pas des données lu à des variables en mémoire...
Sinon, il me semble logique que si un tableau PHP est très long/lourd, le .ini le sera tout autant, faut bien qu'elle soit marqué quelque part les données...
Donc je ne suis pas sur qu'on gagne tant que ça. A tester...

[Sephi-Chan]

Rien ne sera plus rapide qu'un tableau défini puisque ce dernier est directement utilisable. Mais ça n'a pas que des avantages : il peut y avoir des conflits de nommage, c'est peu évolutif (il faut éditer à la main ou écrire un générateur de fichier PHP), ça cantonne à l'application elle-même.

Ça représente donc des risques pour des économies de bout de chandelles (l'apanage des développeurs amateurs).

Dans le monde du développement plus sérieux, on utilise plutôt des fichiers de configuration (YAML, INI et XML, le plus souvent) ou la base de données.

Notez que ce ne sont pas des critiques envers les développeurs amateurs. On passe tous par là.


Sephi-Chan

[php_addict]

Notez que ce ne sont pas des critiques envers les développeurs amateurs. On passe tous par là.

pas de probleme, c'est bien ce que je suis j'apprends tout seul c'est moins rapide...

donc:

- varaibles constantes dans des includes de fichier est ultra rapide, mais dangeureux,

- les données dans la base de donnée plus sûr mais lent,

- les données dans des fichiers de configuration (YAML, INI et XML, le plus souvent) entraine moins de conflit de nommage mais encore faut t il les traiter avec un parser

j'ai bon ?

les class en POO peuvent simplifier la chose, mais je n'est qu'une class pour ma carte et elle fait deja 500 lignes et en fera certainement 1000, ca peut vous paraitre ridicule 500 lignes mais pour moi c'est enorme...

tiens je derapes :hospital: (ais je le droit ?, mais c'est de saison...): combien de lignes font certaines de vos classes POO? (histoire de me faire un peu peur

[Anthor]

combien de lignes font certaines de vos classes POO? (histoire de me faire un peu peur 16

Dépend de ce que tu as à faire.
En général moins de 1000 lignes c'est sûr mais certains composant peuvent atteindre 5000 lignes (Zend_Date)

les données dans des fichiers de configuration (YAML, INI et XML, le plus souvent) entraine moins de conflit de nommage mais encore faut t il les traiter avec un parser

Parser un fichier INI est très simple, en plus c'est natif. C'est pas long, sinon, y'a toujours les return d'array en include

Code PHP :

<?php 

//array.php

return array();



//include

$array = include 'array.php'; 

[My Hotel]

Oui, pour l'ini c'est très pratique, tu peux même définir différentes sections pour gérer des domaines comme l'a expliqué Sephi, ou ce que tu veux d'ailleurs.
Un simple parse_ini_file pour lire, et pour écrire directement à partir de ton interface d'admin, tu peux regarder ici : http://www.siteduzero.com/tutoriel-3-421...s-ini.html
Sinon, la BDD, mais que j'utilise plutôt pour des choses un poil plus complexes, avec plusieurs colonnes qui ne peuvent être simplement résumées dans un .ini.

Bye

[QuentinC]

Pour la sécurité des fichiers .ini c'est normalement pas un problème. Un .htaccess deny from all et paf, le dossier contenant tes fichiers de configuration est inaccessible depuis le web.

De plus pour les fichiers ini, il y a déjà un parseur inclus dans php (cf. parse_ini_file). Pour XML,il y a SimpleXML. IL y a aussi des fonctions pour parser du JSON. J'ai jamais vu de YAML en php par contre.

Mais bon.... XML et JSON pour des fichiers de config ça me paraît lourd et peu pratique par rapport à YAML ou les fichiers ini. JE n'utiliserais les deux premiers que si c'était vraiment nécessaire (nécéssité de stocker des structures arborescentes, ce dont les deux derniers sont de toute façon incapables)

[Anthor]

Ben en soit c'est pas énormément plus dur d'écrire un array dans un fichier

Pour la sécurité des fichiers .ini c'est normalement pas un problème. Un .htaccess deny from all et paf, le dossier contenant tes fichiers de configuration est inaccessible depuis le web.

Non généralement, on met tout ça dans un dossier application parent du dossier public ^^

Mais bon.... XML et JSON pour des fichiers de config ça me paraît lourd et peu pratique par rapport à YAML ou les fichiers ini.

Ça peut être utile dans le cas de config commune en JS et en PHP

[Sephi-Chan]

J'ai lu dans les commentaires de parse_ini_file que la vitesse d'interprétation d'un fichier INI et celle d'un fichier JSON était similaire.

Je dirais donc que JSON est la meilleure alternative pour des fichiers de configuration car ce langage dispose de toutes les structures de données qu'on peut vouloir: string, integer, hash et array (et même null, true et false, mais ils ne fonctionnent pas avec json_decode qui veut des chaînes à double guillemets).

• C'est un fichier séparé : il peut être utilisé par d'autres applications (d'autant que JSON est supporté par tous les langages) ;
  
• C'est extrêmement rapide puisqu'il existe une fonction d'interprétation native (json_decode) ;
  
• Ça renvoie un tableau multidimensionnel (donc on a des espaces de nom), que l'on peut manipuler aisément.
  
• Le tableau retourné est très simple à exporter grâce à json_encode, donc on peut facilement faire une interface pour modifier ce fichier de configuration ;
  

Après avoir pesé le pour et le contre de chaque technique, le JSON sort clairement vainqueur.


Sephi-Chan

[QuentinC]

Non généralement, on met tout ça dans un dossier application parent du dossier public

Encore faut-il pouvoir le faire et encore faut-il avoir php configuré correctement pour laisser accès à un dossier parent du du DOCUMENT_ROOT.