IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Gestion complète de Fichier de paramétrage

Gestion de fichier de configuration dans un format spécifique à l'auteur et facilement modifiable selon vos critères.
Les fichiers peuvent être divisés en section et inclure des commentaires.
Chaque section se voit affecter des propriétés avec des valeurs.
On peut interroger le fichier paramètre par section
La classe gère l'écriture/lecture/modif etc.… des informations.
La syntaxe du fichier de paramétrage est faite pour être simple, intuitive, efficace.
La syntaxe du fichier lui permet d'être modifié facilement par un utilisateur, meme non programmeur. Méthodes de vérification de la cohérence de la structure du fichier parametre. Le code est tolérant avec les espaces parasites.
Il est documenté, compartimenté et modifiable a souhait pour coller à vos besoins.

Developpé en C sharp avec visual studio 2017.
Version 1.4 (D'autres versions à prévoir)
Nos ressources disponibles
Documentation d'une dizaine de page incluse dans l'archive zip et téléchargeable séparément décrivant l'intégralité de la classe, la façon de modifier le code et de l'intégrer dans vos projets.

Avatar de forum
Robot Forum https://www.developpez.com
Le 16/10/2018 à 19:06
Bonjour,

Je vous propose un nouvel élément à utiliser : Gestion complete de Fichier de parametrage

Gestion de fichier de configuration .

Les fichier peut être divisée en section et inclure des commentaires.

Chaque section se voit affecter des propriétés avec des valeurs.

On peut interroger le fichier paramètre par section

La classe gère l'écriture/la lecture des info.

La syntaxe du fichier de paramétrage est simple.

Il peut être tapé facilement par un utilisateur.

Le code est tolérant avec les espaces parasites.

Developpé en C sharp avec visual studio 2017.

Qu'en pensez-vous ?
Avatar de Pol63
Expert éminent sénior https://www.developpez.com
Le 17/10/2018 à 0:20
ca aurait été mieux avec de l'xml, .net core, et des valeurs typées et typables sur autre chose que string, y compris des classes
et je trouve que ca fait beaucoup de code pour pas grand chose du coup

(…)

et pourquoi pas intégrer la création automatique du fichier si celui ci n'existe pas, forcer l'initialisation requise par le constructeur (voire même par un factory static de singleton par fichier qui simplifie encore plus)
et utiliser des propriétés plutôt que des public field !

(…)

au final j'aurais tendance à dire que c'est ni fait ni à faire
étrange parce que le précédent code que tu as posté (je ne sais plus de quoi ca parlait) était quand même mieux ...

(...)

j'ai été retrouver le code en question, c'était la gestion de saisie par textbox en Windows forms
et autant que l'utilisation aurait pu être légèrement plus pratique je n'ai pas réussi à mettre en défaut le système donc c'est plutôt réglo
Avatar de Fab2bprog
Membre confirmé https://www.developpez.com
Le 17/10/2018 à 8:42
Salut Pol63,

Je suis d'accord avec toi globalement mon code de gestion des paramètres est très largement améliorable et je comprends largement tes critiques.
Lors d'une prochaine version j'intégrerai notamment la création auto des fichiers.

En revanche pour ce qui est de l'XML c'est vraiment NON.
On peut faire bien entendu une gestion des paramètres en XML, c'est même beaucoup beaucoup plus simple. Ce n'est pas dit d'ailleurs que j'en fasse une un jour…

En revanche l'XML dans un fichier de paramétrage ce n'est pas forcement bon. Il y a beaucoup de programmeur qui n'en veulent pas. Notamment parce que lorsqu'ils ont un client au tel (notamment lorsqu'ils sont en voiture ) et qu'il leur font ouvrir un fichier de paramétrage pour le modifier c'est du chinois pour eux.

Faire de l'XML c'est plus simple pour nous les programmeurs, mais c'est beaucoup plus compliqué pour des personnes qui ne le sont pas.
C'est peut être parce que je suis un peut old school… mais imagine que ton fichier doivent certaines fois être ouvert par un tech responsable de maintenance ( dans le domaine de la mécanique par exemple), et que ton client soit légèrement réfractaire aux balises ouvrante ou fermante et à l'informatique en general…
Je pense par expérience que les risques qu'il te plante ton fichier XML sont beaucoup grand. D'ailleurs dans l'industrie j'ai beaucoup vu plus de fichier paramètre structuré comme ca qu'en xml. Donc c'est déjà fait par plein de gens (depuis ma connaissance du cobol il y a longtemps … ), et c'est pas étrange du tout. C'est juste une question de philosophie...

Donc oui c'est vrais ca fait pas mal de code, mais en partie parce que justement il n'y a pas d'xml et que justement je me suit embêté pour qu'il n'y en ait pas. C'est vraiment volontaire.
Avatar de Pol63
Expert éminent sénior https://www.developpez.com
Le 17/10/2018 à 11:23
ok, je comprends mieux, c'est une question de point de vue

pour moi un fichier de config n'a pas à être ouvert pas quelqu'un qui ne connait pas (voir même n'a pas à être ouvert du tout)
pour ca je fais une interface graphique (qui va modifier le fichier de config), un fichier de config n'est pour moi que de la persistance locale simple

comme quoi c'est pas ni fait ni à faire ^^

après en restant dans ton optique je verrais quand même bien un public static GestParam GetParamFile(string fileName) {} qui s'occupe de créer le fichier si nécessaire et retourne une instance de GestParam qui elle n'a que les méthodes de manipulation du contenu (avec aussi une méthode static pour delete et rendre le constructeur private)
cette instance pourrait être conservée et éventuellement passée en paramètre ce qui permet de continuer de gérer plusieurs fichiers, mais amène au passage l'abstraction sur le nom de fichier quand on passe l'instance à quelqu'un d'autre
Avatar de Fab2bprog
Membre confirmé https://www.developpez.com
Le 17/10/2018 à 13:36
La encore je dirais que tu as à la fois tord et raison.
Ca dépends comment on voit les choses.

- Oui : un fichier de config n'a pas à être ouvert par quelqu'un qui ne connais pas… en principe.
Mais : Tous les programmeurs font des bugs, touts les ordi connaissent des pannes, des mises à jours système dévastatrices etc... Et donc il existe toujours des évènements plus ou moins inattendus. Sinon les contrats de maintenance logiciel ca n'existerait pas… Donc, je part du principe que les ennuis ca existe, et que pouvoir faire paramétrer quelque chose par quelqu'un d'autre que moi rapidement ca peut avoir de l'intérêt .

-Tu dis : "Pour ca je fais une interface graphique ": La encore je suis tout a fait d'accord avec toi : moi aussi … en principe.
Parce qu'il faut encore avoir le temps de la faire ( ou meme que le client ait le budget pour que tu la fasse, par ce qu'au bout du compte c'est lui qui paie ). Et dans ce cas d'ailleurs mon programme aurais moins d'intérêt puisque dans ce cas précis il vaut mieux effectivement un fichier de paramétrage de type xml.

Personnellement, je trouve que tu as une façon tres saine de raisonner, mais trop théorique pour moi. En fait si j'allais imager tu serait un mathématicien et moi un physicien ou un mécanicien . Moi j'aime bien la beauté des math, mais un moment il faut programmer avec en tête la réalité de la vie, de l'argent et donc tu temps . Je pense que ca serait sympa qu'un jour on développe un code libre ensemble à temps perdu , j'ai peut être meme une idée à te proposer...

Par ce que j'ai une idée de projet qui pourrait rendre vraiment un tres gros service au gens. Mais il me faudrait une personne exactement comme toi. Contacte moi sur mon mail en privé si tu veux que je t'en parle (cf mon code source).
Avatar de ypelissier
Membre habitué https://www.developpez.com
Le 17/10/2018 à 18:24
Avatar de Fab2bprog
Membre confirmé https://www.developpez.com
Le 17/10/2018 à 21:00
Salut,

Ecoute je vais être tres honnête :
D'abord je ne connaissait pas leur existence.
Ensuite, je pense que ce n'offre pas non plus la liberté nécessaire à mon objectif :
Faire un prog un peut a part de ce que l'on vois aujourd'hui ( pas de xml ), qui offre une certaine souplesse et une certaine indépendance vis a vis des API.
Je vais d'ailleurs l'améliorer d'ici la fin de l'année.
Je pense que ce type de code a une durée de vie tres longue...
Avatar de Max
Expert éminent sénior https://www.developpez.com
Le 18/10/2018 à 10:29
Salut

Citation Envoyé par Fab2bprog Voir le message
Je pense par expérience que les risques qu'il te plante ton fichier XML sont beaucoup grand. D'ailleurs dans l'industrie j'ai beaucoup vu plus de fichier paramètre structuré comme ca qu'en xml. Donc c'est déjà fait par plein de gens (depuis ma connaissance du cobol il y a longtemps … ), et c'est pas étrange du tout. C'est juste une question de philosophie...
Je travaille dans l'industrie automobile depuis plus de 10 ans. En environnement Microsoft ça fait bien longtemps que ces fichiers de configuration "plats" de type .ini ont été abandonnés. Sans aucun jugement de valeur, ceux qui restent ne sont que des reliquats du passé dont on ne peut se débarrasser parce qu'on n'a pas le temps ni les moyens de les remplacer (à l'image des gros systèmes et des applications COBOL).

Il n'y a pas de nouveau développement avec ce genre de chose, même pour une appli faite entre deux portes on a souvent besoin de fichiers permettant de faire des structures complexes (typiquement XML, qui lui même perd du terrain face au JSON). Et même dans le cas où un fichier plat suffirait, on utiliserait un XML ou un JSON basique, parce qu'on reste sur des technos actuelles standard et industrialisables, pour lesquelles il existe plein de bibliothèques éprouvées et qui permettront de faire évoluer de fichier de configuration si nécessaire.

Je rejoins Pol63 sur le fait que ça ne permette pas le typage, du coup ça ne permet pas la validation non plus (comme avec un schéma XSD par exemple).

En résumé je trouve ça beaucoup trop limité par rapport à ce qui existe déjà (et qui est déjà éprouvé, débogué, évolutif, etc. enfin que je peux mettre en prod les yeux fermés).
Avatar de Fab2bprog
Membre confirmé https://www.developpez.com
Le 18/10/2018 à 11:01
Salut,

Oui je comprends tes remarques,
Mais bon ce n'est pas ce que j'ai constaté pratiquement non plus dans ma vie…
Apres ce code est libre, il conviendra a certains et à d'autres pas.
Et j'ai prévu de l'améliorer grandement.
Mais j'accepte quand meme tes critiques
Developpez.com décline toute responsabilité quant à l'utilisation des différents éléments téléchargés.