Permettre la surchage de fichier de config

[GuillaumeGas]

Ca paraît une bonne idée ? On ajoute une balise genre <extend>path_to_config_file.xml</extend>. On se content d'appeler la fonction de chargement dessus avant de l'appeler sur le fichier courant, les éléments à nouveau déclarés viennent écraser ceux qui le sont déjà.

[EmileCadorel]

Alors si je comprend bien, c'est une sorte de systeme d'include. Si le fichier n'existe pas on fait quoi ?

[TheNawaKer]

bah deux choses possibles, on lance une exception qui soit arrête le serveur (Bad Config) ou alors on affiche un warning dans les logs. Dans le dernier cas, si une dépendance/paramètre demandé est absent alors on arrête le serveur dans tout les cas.

En cas de doublon, Exception bloquante qui informe l'utilisateur de son erreur (bloquante du fait qu'on ne peut pas choisir la valeur qu'il faut)

[GuillaumeGas]

Si le fichier à inclure n'existe pas, oui soit un warning soit une erreur dans les logs, pas forcément besoin de cracher le serveur... faut voir.

Et non pas d'accord pour les doublons. Je pensais plus à de la surchage de fichier, ça nous permet d'ajouter des param de config au fichier inclu (pour ne pas tout avoir dans le même fichier, devoir faire des copiers collés de fichiers de conf...), et permettre aussi de modifier des params existant dans le fichier inclu (si on inclu un énorme fichier bah on va pas forcément s'amuser à le modifier, on surcharge juste les param existants).

[TheNawaKer]

Ouais mais si le fichier est important, le serveur va finir par planter, alors autant l’empêcher de démarrer si il manque.

Quand je parles doublons, je parle de paramètre en double. Imagine dans ton fichier config tu importe deux fichiers. Le premier défini le paramètre A = 1 et le deuxième dis qu'il est égale à 2. Dans ce cas, on peut pas choisir si A=1 ou A=2 => donc exception Dans le cas d'un fichier importé deux fois, faudra juste ignoré le deuxième appel et mettre un warning

[GuillaumeGas]

Mais non il va pas planter, il va juste pas fonctionner exactement comme prévu. Et puis au pire c'est de la faute au dev^^.

Je parlais aussi des doublons. Je trouve ça dômmage de faire comme ça... Si tu veux modifier un truc dans le fichier inclu, tu vas devoir le modifier toi même alors qu'on pourrait surcharger les paramètres en question. On cherche pas à choisir lequel est le bon, si on re tombe sur le même, ba sa valeur écrase la première puis voilà. Non d'une pipe.

[TheNawaKer]

Bah okay, mais si ça écrase comme ça, le dev risque de pas s'en rendre compte. Perso, je mettrais au minimum un warning afin qu'il puisse le voir. Qu'est ce que tu entends par surcharger ? Dans un fichier de config ça sert à rien d'avoir 15 fois la déclaration d'un paramètre O: Et si c'est un paramètre qui imaginons dans un fichier de config auto-générer alors on a qu'a ajouté un attribut qui force le remplacement et donc ignore la première occurrence (dans le fait, on remplace simplement la valeur par la dernière occurrence trouvé)

Pour finir, par exemple en C#, si tu lance un serveur IIS avec un paramètre incorrecte ou un fichier manquant, il refuse de se lancer en affichant un message d'erreur, parce que ça sert à rien de lancer un serveur si on sait qu'il manque des choses (serveur instable) => du coup, le dev corrige et pouf ça marche :)

[GuillaumeGas]

Ouais c'est pas faux autant stopper le serveur en cas d'erreur dans la config, sinon il va chercher pendant 10 000ans d'où vient le problème. Et quand je parle de surchage, c'est comme lors d'un héritage en C++, on va remplacer le fonctionnement d'une fonction par autre chose, mais on va pas modifier le code de la classe dont on a besoin.

[TheNawaKer]

Ouais, mais je vois pas trop l'interet dans un fichier de config. O:

[GuillaumeGas]

On a pas masse de chose dedans pour le moment... donc on va oublier^^ J'ai juste pris exemple sur un autre serveur (ou je sais plus quel outil) qui proposait cette fonctionnalité pour pas avoir des fichiers de config de 10 000 kms. Bref on ferme pour le moment.