Version imprimable
Salut tout le monde,
une petite question pour savoi qu'elle méthode vous utilisez.
Je cherche un format de fichier qui pourait me permettre de stocker les paramètres de mon application.
A par les fichier ini, et la base de registre, je ne vois pas d autre solution.
:salut:
tu as aussi les fichiers XML et les bases de données.
du côté de la JVCL, tu as également les composants suivants de la page Jv Persistance qui font cela
- JvAppStorage
- JvAppIniFileStorage
- JvAppStorageSelectList
- JvAppRegistryStorage
- JvAppDBStorage
- JvFormStorage
- JvFormStorageSelectList
- JvAppXMLFileStorage
traditionellement j'opte pour un format binaire proprietaire a base de TfileStream.
Suffit de definire une structure de fichier et de copier/lire les données e n respectant cette structure.
un petit plus si ces fichiers doivent être sécurisés ;)Citation:
Envoyé par Clorish
Une classe avec des propriétés publiées peut convenir, en la sauvegardant sur disque.Citation:
Je cherche un format de fichier qui pourait me permettre de stocker les paramètres de mon application.
Tout a fait. LE format etant proprietaire, et arbitraire, les donnéees n'ont de sens que si on connait la structure du fichier. On peut assez facilement la retrouver mais ca limite les petites bidouilles.Citation:
Envoyé par evarisnea
De plus on peut tres facilement le crypter.
Tiens j'ai jamais essayé ca.Citation:
Envoyé par Fabrice ROUXEL 1
Tu as un petit exemple ? ca m'interesse ...
Moi j'ai souvent manipulé les fichiers INI (TINIFILES). La base des registres aussi, et je crois que j'en suis satisfait. Par contre pour une application qui merite d'etre hautement sécurisée, je me crée, comme l'ont mentionné d'autres, je me crée mes propres CFG avec un TFILESTREAM.
sans aller dans la hautement securisé l'interet se trouve dans le fait que l'utilisateur final ne pourra pas venir mettre la panique dans le fichier de config :)
Je reserve les fichiers ini (tres bon format d'ailleur) seulement aux application dont l'utilisateur peut editer le fichier de confg. Ils me servent egalement a generer des scripts de chargement, ou des formats de fichiers simples sans avoir a developper un editeur specialisé ou utiliser des formats complexes comme le XML
Sachant maintenant que vista est plus 'sécuisé' au niveau des droits,est ce que des solutions ne deviennent pas obsolètes ;du style les fichiers Ini ou la base de registre ?
ne pas confondre securitee des données et integrites des données.
Moi quand je parlais de securiser un fichier de config c'etait plus dans l'optique de conserver l'integritee des données.
C'est a dire eviter que l'utilisaeur plante l'application suite a une mauvaise manip des fichiers de config.
A savoir que les utilisateurs on souvent la facheuse habitude de bidouiller un peut tous les fichiers ;)
Ensuite, vista est peut etre plus securisé en matiere de droits d'acces, ca n'empeche pas que l'utilisateur ayant les droit vienne tout de meme mettre la panique dans les fichiers de configs ;)
D'autre part, la BdR, elle permet surtout de pouvoir moduler les chemins d'acces en fonction du ou des repertoires d'instalation et de partager certaines données qui se trouvent regrouppées dans un endroit dont le chemin est connu. A noter que la BdR est une sorte de fichier ini geant dont le chemin sur le Hdd ne change pas d'un systeme a l'autre :D
Cette fonctionnalitée (partage et accessibilitée) n'a rien a voir avec la gestion des droits d'acces.
Ha j'oubliait, la Bdr permet aussi de facilement specialiser et/ou parametrer l'application en fonction des utilisateur, que l'on peut aussi gerer via les repertoires du compte utilisateur mais c'est moins pratique a mon gout ;)
[Edit] Derniere chose : Tout le monde n'a pas encore Vista .... et c'est a mon gout encore un peu restrictif de limiter l'usage a Vista, surtout face aux enormes problemes de migrations XP/Vista :D
On créé une classe TConfigClass dérivée de TComponent par exemple, qui contient dans la section published des proprietées de configuration du soft.(font, contenu de combobox, d'items de menus etc).Citation:
Citation de Clorish:
Fabrice ROUXEL 1 a écrit :
Une classe avec des propriétés publiées peut convenir, en la sauvegardant sur disque.
Tiens j'ai jamais essayé ca.
Tu as un petit exemple ? ca m'interesse ...
Cette classe est chargé/sauver via TFileStream et Read/WriteComponent.
Une interface accessible via un menu permet de personnaliser la configuration dont les champs initialiseront les properties de la classe.
On ajoute un TOpen/SaveDialiog + 1 variable globale ConfigObj + 1 méthode qui initialise le logiciel en lisant les propriétés de la classe avec un test au chargement sur l'existance du fichier de config.
PS/ Sub0 a une démo de sérialisation de classes.
Claudius s'est également penché la dessus en proposant une démo en lien sur un thread.
Le concept je vois tout a fait.
C'est le Read/WriteComponent que j'avais oublié en fait :)
Par contre ca marche bien ? parce qu'en general l'ecriture de variable type pointeur (font/string/objets/...) ca passe plutot mal ....
J'imagine que les property ne doivent avoir aucune reference mais que des objets cree en interne non ?
J'ai pas trop confiance en ce genre de methode :) (a tord surement ;))
je prefere implementer une fonction toute simple saveconfig qui prends en paramettre l'objet config et ecrit via les methodes classiques tous les champs de l'objet et de ses sous objets si il en existe.
Une bonne structure et ca passe tout seul, et au moins je sais ce qui est ecrit ;)
Pour des fichiers de configuration la solution qui s'appuye sur les records et les fichiers .ini (ou XML) est tout de même ce qu'il y a de plus souple.
( Il n'y avait même que cela dans tout le soft lors de ma dernière mission, ni poo, ni rtti, ni sérialisation).
Dans le cas d'une composition les objets seront créés en interne mais l'aggrégation est tout aussi valable.Citation:
J'imagine que les property ne doivent avoir aucune reference mais que des objets cree en interne non ?