Discussion :

[kerinel]

J'aurais une petite précision a demander concernant les propriétés stockées dans un fichier .properties via un objet Properties. Cet objet a une méthode setProperty(String cle,String propriete) et on ne peut donc sauvegarder que des Strings. C'est un peu limitatif non ?
Car lorsque je veux stocker la couleur de fond de la fenêtre "Bidule" ou la police utilisée pour le JLabel "toto", il serait plus simple de stocker directement un objet Color ou un objet Font ? Pour la couleur je récupère la valeur RGB ce n'est pas très complexe, pour la police je n'ai pas encore réfléchi mais il doit bien y avoir une solution facile aussi. Mais a chaque fois cela demande de reconstruire l'objet a partir de nombreuses propriétés que on aura enregistré.
Ma question est donc n'y a-t-il pas plutôt intérêt a faire sa propre Hashtable pour stocker ses objets sérialisables et sérialisés divers et variés et les ressortir tout prêt ?
merci pour vos réponses

Bon code
kerinel

[leyee]

Bonjour,

Il faut voir cela comme la possibilité de réaliser un fichier de configuration pour une application par exemple. En ce sens un ensemble de couples clé-valeurs sous forme de chaine de caractere est suffisant. Si tu souhaite paramétrer toute ton application a partir d'un fichier, effectivement la serialisation reste une meilleure solution ...

[kerinel]

OK donc je demande trop à Properties si j'ai bien compris. je vais m'orienter vers une Hashtable alors.
Merci beaucoup,

Bon code,
kerinel

[iohack]

Une vision personnelle :
le property a l'avantage d'être modifiable par l'utilisateur de l'application, ce dernier n'ayant pas à conaitre le source pour effectuer la modif (simple fichier texte à éditer). Deuxième avantage : le property peut être modifié dynamiquement pendant que l'application tourne.
La sérialisation, plus performante, est elle réservée au développeur de l'application et est implémentée directement dans le code source --> L'utilisateur lambda de l'application n'a aucun control sur ces propriétés.

Une petite contradiction à ce que je viens de dire : il est possible pour l'utilisateur lambda de controler la sérialisation en passant par une IHM (exemple d'un menu "configuration"). Mais dans ce cas, cela prends plus de temps de développement (nécessité d'écrire les liens IHM <--> valeures <--> sérialisation). Cela peut être un peu trop pour une application "basique", dans tel cas, le property est beaucoup rapide.

PS Pour beaucoup d'applications, on retrouve les deux méthodes simultanément : une IHM de configuration + possibilité d'éditer directement le fichier de configuration au format texte.

[kerinel]

D'accord avec toi si l'utilisateur sait/veut fouiller dans un fichier texte et savoir à quoi correspond telle ou telle valeur ... Pas certain que cela rende la modification de paramètre plus facile si on commence à avoir un certains nombre de variables. D'accord on peut alors utiliser plusieurs fichiers, mais l'utilisateur devra alors savoir que la couleur de la fenêtre "toto" se contrôle dans tel fichier et la police du tableau "riri" dans tel autre fichier...
Je pensais bien me tourner vers un menu configuration et donc une IHM. Du coup je pense que la possibilité de sauvegarder directement une couleur sera plus pratique.

Une petite question au passage : dans ces fichiers properties, y-a-t-il moyen d'insérer des lignes de commentaires ? car j'en utilise pour l'internationalisation (où là c'est parfaitement suffisant d'utiliser seulement des Strings) et je voudrais pouvoir séparer un peu des fichiers qui pourrait être un peu volumineux ou un peu fouillis.

bon code,
kerinel

[adiGuba]

D'accord avec toi si l'utilisateur sait/veut fouiller dans un fichier texte et savoir à quoi correspond telle ou telle valeur ... Pas certain que cela rende la modification de paramètre plus facile si on commence à avoir un certains nombre de variables. D'accord on peut alors utiliser plusieurs fichiers, mais l'utilisateur devra alors savoir que la couleur de la fenêtre "toto" se contrôle dans tel fichier et la police du tableau "riri" dans tel autre fichier...

Oui mais c'est possible, alors qu'il n'est pas possible pour humain de modifier directement un fichier sérialisé...

Je pensais bien me tourner vers un menu configuration et donc une IHM. Du coup je pense que la possibilité de sauvegarder directement une couleur sera plus pratique.

Même si tu utilises une IHM, tu peux très bien utiliser des fichiers properties : chaque élément de configuration peut très bien être converti en "texte" (par exemple pour une couleur il suffit de sauvegarder la valeur des 3 couleurs de base RGB).

Une petite question au passage : dans ces fichiers properties, y-a-t-il moyen d'insérer des lignes de commentaires ? car j'en utilise pour l'internationalisation (où là c'est parfaitement suffisant d'utiliser seulement des Strings) et je voudrais pouvoir séparer un peu des fichiers qui pourrait être un peu volumineux ou un peu fouillis.

Tu peux utiliser le # en début de ligne pour qu'elle soit ignorée à la lecture...

Par contre la classe Properties a un gros défaut : lorsque tu utilises la méthode store() pour sauvegarder, tous les commentaires ainsi que l'organisation du fichier est perdu (on se retrouve avec un fichier avec les lignes key=value "en vrac").



Enfin, si c'est pour configurer une application graphique tu pourrais éventuellement tu tourner vers Fuse

a++

[bouye]

Même si tu utilises une IHM, tu peux très bien utiliser des fichiers properties : chaque élément de configuration peut très bien être converti en "texte" (par exemple pour une couleur il suffit de sauvegarder la valeur des 3 couleurs de base RGB).

Ou sous sa forme hexadecimale/HTML, etc.... de meme pour les polices ou tu peux stocker les composantes separement (font.familly, font.size, font.style) ou bien utiliser un codage sur une ligne (ce que font certaines applications unix pour leurs fichiers de proprietes/ressources, comme par exemple : Times-9-plain). Le probleme est exactement le meme quand on utilise l'API de Preferences, on peut ne pas avoir envie de stocker une version serialisee de l'objet.

Par contre la classe Properties a un gros défaut : lorsque tu utilises la méthode store() pour sauvegarder, tous les commentaires ainsi que l'organisation du fichier est perdu (on se retrouve avec un fichier avec les lignes key=value "en vrac").

Ce qui peut se corriger tres rapidement en surchargeant/reecrivant store() pour creer une List<String> triee a partir du keySet() de la table. Resp avec la methode qui lit le fichier histoire de conserver les sections et les commentaires... ce n'est pas vraiment le format de fichier qui soit le plus complique qui soit.