Discussion :

[forum]

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 ?

[Pol63]

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

[Fab2bprog]

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.

[Pol63]

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

[Fab2bprog]

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).

[ypelissier]

Bonjour,
Projet int�ressant mais pourquoi ne pas avoir utiliser les API Windows directement disponible dans le Kernel32 ?

Pour la lecture :
http://pinvoke.net/default.aspx/kern...ProfileSection
http://pinvoke.net/default.aspx/kern...eProfileString

Pour l'�criture :
http://pinvoke.net/default.aspx/kern...ProfileSection
http://pinvoke.net/default.aspx/kern...eProfileString

[Fab2bprog]

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...

[Max]

Salut

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).

[Fab2bprog]

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

[Fab2bprog]

Je voudrais ajouter une chose :
Certaines personnes veulent du JSON, d'autres de l'XML.
Certains veulent utiliser des API Kernel32 (donc non portable ).
Certains se fichent des normes et veulent simplement un truc qui marche
Certains veulent un fichier modifiable facilement par un tech qui se chargera de l'installation du prog.
Certains manquent de temps pour faire les choses et ce programme les aidera.
Certains veulent un code qui part de z�ro pour pouvoir le modifier comme ils veulent et ne pas �tre contraint par une philo existante pour une raison x qui leur appartient.
Certains veulent un programme sans aucune instruction sp�cifique � la plateforme pour un max de portabilit�.
Certains doivent s'aligner sur des normes existantes, et ils n'ont pas le choix de faire autrement par ce qu'il y a 20 ans de code derri�res.

En fait un fichier de param�trage il doit surtout �tre comme on veux qu'il soit�

Et j'aurais put avoir un programme qui g�re du json ou de l'xml et qui soit bourr� de bug aussi� m�me si l'utilisation d'instruction sp�cialis�es diminue ce risque. D'ailleurs il existe aussi des bug dans des API, Windows n'est pas inconnu non plus pour �tre un syst�me absent de tout bug.. Ca ne serait pas la premi�re fois qu'un caract�re parasite fasse planter une API par exemple, ca arrive souvent d'ailleurs lorsque les fichiers sont �dit�s sur des OS diff�rents ou des version OS diff�rents. Mais je vous rassure mon programme n'est pas a l'abris de cela non plus. Maintenant c'est sure : le code aurait �t� plus court et plus simple.

Voyez ce code comme une proposition ORIGINALE , vous pouvez la refuser ( c'est pas grave) , faire des propositions d'am�lioration suppl�mentaire comme Pol63.

Je vais essayer de tenir compte de tout ca dans une prochaine version , mais ca restera du sp�cifique.
Pour l'instant c'est mon premier jet (1.0).

[ypelissier]

Personnellement je ne disais pas cela pour te critiquer, j'ai moi-m�me eu � faire ce genre de gestionnaire de configuration sp�cifique en partant d'un fichier INI (disposition dont l'explication n'a que peu d'int�r�t en soit puisque c'�tait une volont� cliente). Je ne pouvais pas utiliser les API Windows car je ne connais pas � l'avance le nom des param�tres et des sections. J'ai donc pars� le fichier � la mano, comme ce que tu proposes.

[Fab2bprog]

Salut,

J'ai fait beaucoup d'am�liorations depuis ma version 1.0
- Ajout de 14 m�thodes dans la classe permettant de g�rer avec la plus grande souplesse possible
le fichier parametre. Au total vous pouvez maintenant g�rer le fichier de parametre avec 22 m�thodes diff�rentes.
- Meilleur pr�sentation du code.
- Documentation plus pr�cise.
- Corrections de bug et optimisations diverses.

Je projette de l'am�liorer encore tres grandement.
Je pense notamment que dans les versions futures je vais inclure des notions de JSON et d'XML (j'ai quelques id�es sous le coude...) .

[Fab2bprog]

Personnellement je ne disais pas cela pour te critiquer, j'ai moi-m�me eu � faire ce genre de gestionnaire de configuration sp�cifique en partant d'un fichier INI (disposition dont l'explication n'a que peu d'int�r�t en soit puisque c'�tait une volont� cliente). Je ne pouvais pas utiliser les API Windows car je ne connais pas � l'avance le nom des param�tres et des sections. J'ai donc pars� le fichier � la mano, comme ce que tu proposes.

Et comme je le disait , on a pas toujours le choix, y compris financi�rement de dire non � un client�
Il est certain que lorsque l'on sort des normes bien standardis�s comme l'XML, et que l'on d�veloppe du code de A � Z, on risque toujours des bugs. L'investissement , le temps, les couts augmentent...
C'est aussi pourquoi j'ai essay� de faire une gestion compl�te de fichier parametre facilement modifiable et adaptable ( peut �tre aussi � ce que tu as fait et � d'autre projets que tu aura dans le futur ?)
Avant d'ajouter de nouvelles fonctions, de vais dans ma prochaine version 1.5 rajouter encore des tests de coh�rence ( structure et data ) et pousser encore plus loin la recherche de bug et l'optimisation du code. Le but c'est que la version 1.5 soit vraiment la plus solide possible.
Je ne connait pour l'instant pas de bug dans cette version 1.4.
Apres la version 1.5 j'ajouterais certaines fonctions qui am�liorerons les possibilit�s offertes par le programme.