Define ou array

[Knah-Tsaeb]

Les paramètres sont définient via des define(). Pourquoi ne pas utiliser un array().

Le problèmes des define(), c'est que par définitions ils sont définie, on ne peut pas les changer dans le script. Alors qu'avec un array(), au besoin on peut les redéfinir.

Je pose la question parce que j'aimerais bien faire un peu comme les CSS, pouvoir charger (include) un fichier contenant les options de l'utilisateur. Idéalement migrer le contenu de config.php dans l'index (en haut du fichier) et inclure le fichier config.php (si il existe) avec les paramètres utilisateur. Ainsi lors d'une mise à jour pas besoins de remodifier le fichier index.php pour remettre ses paramètres personnalisés.

[ArthurHoaro]

Le problèmes des define(), c'est que par définitions ils sont définie, on ne peut pas les changer dans le script. Alors qu'avec un array(), au besoin on peut les redéfinir.

Le principe c'est justement que les paramètres de configuration sont censés être des constantes et ne pas être modifiés.

Normalement, le fichier de configuration utilisateur ne devrait pas bouger, et ne pas gêner la MàJ. Dans les faits, c'est vrai qu'on a pas arrêté de le modifier.

Je pense que ce qui ressort de cette question, c'est peut être une restructuration du fichier config.php pour ne garder que ce qui est vraiment destiné à l'utilisateur (je pense par exemple aux traductions). Si on arrive à le fixer, rien ne t'empêchera d'ajouter des paramètres supplémentaires.

A creuser, donc.

[Knah-Tsaeb]

Ok ça marche, j’attendrai la stabilisation de la structure.

[mitsukarenai]

Je pense à un truc: si à l'avenir on fait un mécanisme de mise à jour automatique ("je clique sur le bouton et PHP se charge de tout bien mettre à jour sans rien casser"), la config doit être bien parsable et extensible (notamment à l'ajout de paramètres). Variables, constantes, array, feuille INI ou JSON.. va falloir harmoniser tout ça :)

[Knah-Tsaeb]

Pour moi c'est juste l'horreur ce fichier config. J'ai rajouté des options persos, à chaque commit, faut que je remette le fichier d'origine, que je sauvegarde le fichier et après en recommence dans l'autre sens. Après je deploi sur le server je balance mon fichier de config, quand j'update on recommence.

[ArthurHoaro]

@mitsukarenai On n'y est pas mais je ne pense pas qu'il soit nécessaire que ça soit parsable. S'il y a des paramètres à ajouter, on les ajoute à la fin du fichier. La modification de paramètre ne devrait normalement pas avoir lieu.

@Knah-Tsaeb Je me suis fixé sur les define (sauf la liste des fermes XSAF, pour itérer dessus). Dans l'idée ça correspond à ce que tu attends ?

[Knah-Tsaeb]

@ArthurHoaro non tu n'y est pas encore. Je sait pas comment tu fait tes mises à jour. Moi j'utilise Git, comme le fichier de config est versionné, à chaque update, il écrase mon fichier de config en prod, ce qui m'oblige à le réédité à chaque update. Idem quand je code, je travaille en locale donc à chaque commit faut que je fasse gaffe de ne pas commiter mon fichier de config. C'est pour ça que je préférerais utiliser un fichier à part pour modifier les paramètres de config. Comme le fait Shaarli par exemple. On définie des paramètres en dur puis on charge le fichier de config perso si il existe. Comme ça on garde la config par défaut que les dev pensent être la plus adapté, et ceux qui veulent les modifier peuvent le faire sans tous chambouler à chaque update.

@mitsukarenai pas besoin de la faire parssable. Si tu met à jour tes fichiers, le fichier de config est écrasé par le nouveau. C'est normal et c'est bien. Mais pas le fichier de config de l'utilisateur. Si tu ajoute un nouveau paramètre comme il est définie par défaut, pas de problème, la config est appliqué. Si l'utilisateur veut changer ce paramètre il édite son propre fichier de config. Si tu supprime un paramètre et que k'utilisateur l'avait définie dans son propre fichier de config, bah il ne se passe rien, il as juste une ligne en plus dans son fichier de config perso. Si tu change profondément un paramètre par exemple $maVariable = '1' devient $maVariable = 'du texte' et que l'utilisateur a lui même redéfinie ce paramètre dans son fichier de config perso en $maVariable = '0'. Et bien il suffit de l'avertir qu'un paramètre vient de changer et qu'il doit éditer son fichier avec le nouveau format que tu as définie.

En même temps je comprend bien qu'on as tous des visions et des pratiques différentes. Et il est difficile pour moi de suggérer des modifs sur votre projet. J'ai beaucoup de respect pour votre travail, je ne voudrait pas que mes suggestions ou demandes de pull request soit mal perçu et passe pour des "vous n'y connaissez rien regardez comment il faut faire". Je suis pas développeur à la base, je ne me base que sur mes propres expérience et un peu celle des autres. Toutes mes demandes sont plus des réflexions que des critiques. Je le fait vraiment pour aider. Parfois, quand on ne connaît pas les gens, certaines de nos actions peuvent ne pas être bien perçu et passez pour de l'ingérence, mais ce n'est pas dans mon caractère. Donc voilà je vous aime et j'aime ce que vous faites, continuez comme ça, c'est vraiment du bon boulot.

[ArthurHoaro]

D'accord, d'accord. Donc je vais essayer de recadrer tout ça :

Moi j'utilise Git, comme le fichier de config est versionné, à chaque update, il écrase mon fichier de config en prod, ce qui m'oblige à le réédité à chaque update

J'utilise aussi évidemment Git (mais ma version de dév n'a pas de paramètres spécifiques). Quand il y a un conflit, c'est que le fichier de config a été modifié sur le repo.

Là, tout de suite, c'est normal que mon commit crée des conflit avec tes modifs, puisque j'ai complètement changé le fichier config.php. L'idée, comme décrit dans le message du 195a6644f5146d33b833851cf3c2ed3e25e65f4c, c'est qu'on ne touche plus au fichier à partir de maintenant (et au moins jusqu'à une prochaine version).

Dans le détail, voilà ce qu'il se passe :

1. Tu modifies ton fichier config.php avec tes paramètres spécifiques.
2. En phase de dev, j'ajoute une option au fichier config.php, que je pushe sur le repo.
3. Quand tu veux mettre à jour, Git veut que tu commit tes changements pour savoir quelle version de config.php il doit conserver (la tienne ou la mienne).

Dans un cas, tu perds ton paramétrage, dans l'autre ta ferme ne fonctionnera plus parce qu'il va manquer un paramètre. Et après quelques tests, je ne vois pas comment résoudre ce problème simplement, à part essayer dès maintenant de modifier le fichier le moins possible (côté développeurs).

Quant au comportement que tu décris dans ton deuxième paragraphe... Je n'entrevois même pas le moyen de faire ça ; et encore moins simplement.

C'est d'ailleurs, je pense, pour ça que des outils comme Wordpress embarquent leur paramétrage comme des données, en base.

PS : Merci pour tes remarques ceci dit, quand on a le nez dedans, on n'a généralement pas la meilleure vision des problèmes/besoins d'améliorations que peuvent rencontrer les utilisateurs.

[Knah-Tsaeb]

Je vais essayer de te montrer un exemple demain (si j'ai pas trop de boulot).

[Knah-Tsaeb]

https://github.com/Knah-Tsaeb/test_config J'ai fait ça rapidos, juste pour donnée une idée du truc.

[ArthurHoaro]

OK, j'ai pigé, tout simplement. On s'embrouille facilement avec les longues explications. :-)

Arthur Hoaro - http://hoa.ro

• Envoi Mobile -

Knah-Tsaeb notifications@github.com a écrit :

https://github.com/Knah-Tsaeb/test_config	J'ai fait ça rapidos, juste pour donnée une idée du truc.
---
Reply to this email directly or view it on GitHub:
https://github.com/mitsukarenai/Projet-Autoblog/issues/9#issuecomment-16226926