Herve Agnoux: >> J'ai une appli GUI. Comme d'hab il y a de nombreuses options. >> Jusqu'� present je me suis d�brouill� avec un fichier de propri�t�es.
Idem. >> Mais cela devient ing�rable. Il y en a trop. Est-ce genant ? Quels sont les problemes ? >> java les sauvegarde dans >> le fichier dans l'ordre qui lui plait (c'est � dire l'ordre des >> hashcodes des propri�t�s, je subodore, qui n'a rien � voir avec un >> quelquonque ordre humain), etc. Exact. Mais la question principale est: comment les editer ? >> De plus la situation se complexifie, puisqu'il faudrait que mes >> options soient tant�t accessible depuis un menu, tantot ne le soient >> pas. Dans ce cas, ce n'est pas la valeur des proprietes qui posent probleme mais leur statut (type, niveau, ...). En gros, les meta-donnees ;-) >> Je vois plusieurs directions pour me d�brouiller : le XML, les beans, >> les langages de scripts... Ou encore les beans serialises en XML. >> Y a-t-il des "bonnes pratiques" sur ces questions ? Des trucs tout >> fait, des conseils, ou n'importe quoi d'autre ? Pour ma part, j'en reste aux proprietes (moyennant une surcharge). Ma classe derivee propose des accesseurs types, gerent les valeurs par defaut, ... et pourrait eventuellement faire un enregistrement trie. > moi j'hesiterai entre XML et preferences (si t'es en 1.4 cote client) > en dehors de l'effet de mode, la syntaxe XML est unifiee et > comprehensible, tandis qu'entre httpd.conf, main.cf de postfix ,et la > config de samba etc... autant de configs differentes... Vrai mais les proprietes Java ont un format clair et unique. > en plus le cle=valeur a ses limites qu'XML permet de depasser... XML apporte l'ordre des entrees et la multiplicite des entrees de meme nom (dans ce contexte). En gros, c'est un peu lourd (necessite de SAX ou DOM plus code pour mapper) et le fichier reste (un peu plus) difficile a editer a la main. Pour ma part, je prefere en rester encore aux proprietes. Et si je devais changer, je prendrais l'option "bean serialise en XML". Guillaume
