Discussion :

[koolkris]

Bonjour,

J'aurai voulu connaitre la meilleure façon de stocker des options, des paremetrages d'une application. Est ce que c'est mieux de le faire dans une base de données, dans une fichier ini ? un cfg ? est ce qu'on peut le verouiller par un mot de passe ? est ce qu'on peut le rendre hors d'acces pour l'utilisateur ?

merci

[Tardiff Jean-François]

Bonjour,

Pour mas part j'utilise des composant de ce type.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
TMyOptions = Class(TComponent);
 
Public
  constructor Create(Owner: TComponent); override;
  destructor Destroy; override;
 
  Procedure SaveToFile(FileName: string);
  procedure LodFromFile(FileName: string);
  Assign(TMyOptions);
published
  property option1: ...   etc..
end;

Je trouve cela pratique car les options peuvent être stocké, dupliqué (via assign), sauver or recupérer de manière simple.

Pour les save to file j'utilise en général un stockage xml, qui est plus adaptable que les fichiers ini (en faite c'est une arborescense).
si je désire un mot de passe je ne sauve pas dirrectement mon fichier à partire de mon XMLDocument (le composant qui permet de créer le fichier xml), mais je le récupère dans un Tstringlist, que je code ligne à ligne (avec des composant Libre trouver sur internet) avant de le sauvegarder.

[vanquish]

Tout dépend du volume de tes options.
Cela dépend aussi si les options sont liées à la station ou pas.

Si ton application est multiposte et qu'un utilisateur donné, peut se connecter depuis n'importe quelle station et retrouver ses options, alors le mieux est de les stocker dans une base de données centrale (surtout si ton application en est déjà pourvu pour d'autres données).

Sinon, en monoposte, sous, Windows l'endroit normal pour stocker des options est la base de registre.

particulièrement dans la branche
HKEY_CURRENT_USER/Software/Nom_Société/Nom_Soft

C'est suffisement planqué pour qu'un utilisateur lambda n'aille pas y fourrer son nez et suffisament accessible pour, en cours de développement, les éditer à la main.

[Tardiff Jean-François]

L'avantage d'avoir un composant ets justement de permet une évolution voir un multi choix.

Personellemnt je n'ai pas besoins de gestion centralisé par une base de donné. Mais si le besoin s'en fais sentire, je peux modifier le LoadFromfile, Save Tofile, ou mieuw encore implementer un LoadFromBase saveToBase. La dernère solution permet de choisir des options local ou dans une base. Il suffit d'appeler une ou l'autre des fonction de "save" ou "load". De toute manière, il doit toujour y avoir un minimume de paramètrage local, ne serai'ce que pour indiquer ou aller chercher la base de données.

[vanquish]

Personellement, j'utilises des classes pour TOUT.
Donc pour les options.

Mais la question n'était pas comment gérer, mais où stocker (ini, cfg ...) !

Sinon pour la gestion, ma classe je n'utilise pas une property par option, comme tu sembles le faire, mais une liste d'options nommées. Ainsi je peux ajouter autant d'option que je veux sans toucher à ne serait-ce qu'une seule ligne de ma classe.

Mon code ressemble à cela

const optTYPE_SAUVEGARDE = 'TYPE_SAUVEGARDE' ;

if gOptions.Option( optTYPE_SAUVEGARDE , 0 ).AsInteger = 0 then ...
(0 représente la valeur par défaut)
ou
gOptions.Option( optTYPE_SAUVEGARDE ).AsBool := True ;
ou
gOptions.Option( optTYPE_SAUVEGARDE ).Save ;

Après selon le mode de gestion, l'option est lu dans une base de données ou dans la registry (défini dans le create).
J'ai un objet par type d'option (globale tout utilisateur, globale par utilisateur et locale lié à la station) avec un mode de stockage différent pour chacun.

J'ai écris la classe il y a 3 ans en tout début de projet et depuis je n'ai pas eu à y toucher, alors que pourtant, j'ai créé des options de tout poil.
Pour créer une nouvelle option, j'ai juste besoin de créer une nouvelle constante avec un libellé (et encore, même ça, je pourrais m'en passer - mais cela évite les erreurs suite à des fautes de frappes).

[Tardiff Jean-François]

Personellment je ne suis pas un fanaitique de la base de registre.

A trop l'utiliser on en vient à avoir beaucoup de mal à eb maitriser la "propreté" (nettoyage suite à des passages de versions, ou a des control C "sauvage" en cour d'installation par exemple).

Je trouve personellment un fichier de type XML plus propre. Mais ce n'est qu'un point de vus.

J'ai aussi eu le problème d'avoir a passer d'un fichier local à un fichier base access ou autre suivant les versions, pour ne pas dir l'age du capitaine.

Dans ce cas avoir des sauvegarde specialisé (saveToFile saveToXml SaveToExcel etc..) est trés pratique.
Il existe aussi le cas mixte.
Une option est lus en local (XML, Ini registre ou autre) et le reste est lus quelque part (sous entendu l'option lu en local indique ou allez chercher le reste des options).

Quand à gerer un gestionnaire standard, tous simplement parce que je n'en avais pas réelement l'utilité.
les options que je sauvegarde sont souvent des options "composé" avec
Une appli qui sauvegarde les options de x composant, chaquen des composant contient des sous composant qui sauvegarde leurs options etc .. Je caine donc les save les un avec les autres et la structure XML est bien adapter à cela. Le registre aussi, mais je n'aime pas trop. Surtout qu'il m'est demandé de pouvoir sauvegarder X paramètrage différent sur disiquette pour pouvoire les rétablire pa un simple copy.

[koolkris]

Merci pour toutes vos reponses je pense que ça va bien m'aider !