Salut,
voilà, en fait, je voudrais savoir ou il est conseillé de stocker les paramètre d'un programme ...
Imaginons par exemple que l'on veuille stocké euh ... Le nom du programme, et le thème utilisé.
Eh bien, où vas-t-on stocker ces infos ?
Bien sûr la première chose qui me vient à l'esprit, c'est de mettre ça dans une table SQlite avec un champs content et un champs type .. par exemple :
|-- type --|-- content --|
|------------------------|
|-- nom --|-- MyProg ---|
|-- color -|-- Orange ---|
Bon, mais la bdd, c'est plutôt lourd, même si Sqlite est réputé rapide ...
alors j'ai pensé au .ini , mais en faisant des recherches, j'ai entendu parler des .properties ...
Et je ne sais ce qu'il faut que j'utilise ...
qu'es-ce qui est conseillé ?
qu'es-ce qui va le plus vite ?
Et juste par curiosité, qu'es-ce qui est le plus facile
Mais ce que je cherche, c'est le plus efficace (donc le plus rapide).
A c'est intéressant que ce soit en build in ...
D'accord, j'attends l'avis des autres ...
PS
au passage, je suis content de voir que le sdz n'est pas inactif le matin, même sur le forum Java qui est généralement désert à cette heure.
EDIT
Oui, ça me paraît drôlement pratique ...
Mais une question, es-ce que un getProperty() va aussi vite que si on garde sa valeur dans une variable ?
Par exemple, si j'ai besoin de la valeur "color" 10 fois dans ma classe, il faut que je fasse un getProperties à chaque fois, ou es-ce plus rapide en stockant la valeur de getProperty() dans une variable, et en utilisant cette variable dans la suite du code ?
Je suppose que cette dernière solution est mieux ...
tout dépend de ce que getProperty vas chercher la valeur dans la mémoire vive ou sur un fichier ...
La classe Properties étend la classe HashTable. Les properties sont chargées en mémoire vive au moment du load et un get équivaut donc à un get sur une HashTable.
Citation : shakhal
serialisation xml pour moi
Avec un format propre et un parser à faire sois même ou via une API spécifique ?
A noter que Properties supporte deux formats
Un format classique clé=valeur
Un format XML
A+,
"'But I don't want to go among mad people,' said Alice. 'Oh, you can't help that,' said the cat. 'We're all mad here.'" Lewis Carroll
D'accord, je pense que je vais opter pour properties ...
Voilà, j'ai trouvé un exemple ici : http://www.commentcamarche.net/forum/a [...] er-properties
Mais es-ce que c'est bien comme ça ...
Je doute pas que ça marche, seulement, je voudrais pas utiliser un code bricoler qui est pas très performant ...
C'est bien comme ça qu'il faut faire ?
je continue à me renseigner, merci bien.
D'accord, ça marche impec, il ne me reste plus qu'à faire un getProperty("nomDeLaPropriété"); et une setProperty("NomDeLaProprieté", "valeur");
Je ne sais pas trop encore comment je vais faire ...
Parcourir tout les ligne et faire un matches pour savoir si c'est la bonne ...
Ca me paraît le plus simple ...
Mais dans ce cas, c'est plutôt lourd ... non ?
comment font les moteurs de base de données pour faire ça ?
Oh pardon, c'est compris dans la class Propreties !
Suis-je bête, j’essayai de le faire sur ma classe demo !
Donc ça marche, merci beaucoup !
Je te conseille les fichiers properties en format classique. C'est le plus simple et le plus rapide.
Ensuite, ça dépend de ce que tu veux stocker. Les fichiers properties sont à peu de choses près des fichiers ini avec une syntaxe clé=valeur, donc ils sont limités à des paramètres qui peuvent se ranger dans une map, ou autrement dit, une structure associative type dictionnaire.
Si tu as besoin d'une structure plus évolué, tu peux te tourner vers XML. AVec XML, tu introduis une possibilité de hiérarchisation arborescente. Suivant tes buts, ça peut devenir intéressant.
Par contre, je suis d'avis que XML est généralement utilisé à tort, dans des cas où il n'est pas nécessair. XML ne devient réellement utile que s'il faut structurer les informations en arbre, ce que les 3/4 des logiciels se configurant via XML ne font pas vraiment avec profit (ce que je dis là n'est pas propre aux applications java, c'est une tendance générale). Ainsi la forme XML des properties,me paraît être une totale hérésie, puisque ce n'est toujours ni plus ni moins qu'un dictionnaire, même sous sa forme XML.
IL ne faut pas oublier que XML est moins lisible et moins facilement modifiable à la main qu'un properties classique, en plus d'être parsé et regénéré plus lentement. JE suis donc d'avis qu'il faut une vraie bonne raison pour l'utiliser.
Ensuite, il y a les bases de données. C'est 100 fois plus lourd que XML, même SQLite, et on ne parle même pas de MySQL. Pour la config d'un programme, franchement, c'est lourd et ça ne sert à rien, soyons réalistes. Si on n'utilise déjà une base de données pour autre chose d'accord, mais sinon, ne sortons pas un tank pour abattre un moustique, c'est totalement contre-productif.
Par contre, je suis d'avis que XML est généralement utilisé à tort, dans des cas où il n'est pas nécessair. XML ne devient réellement utile que s'il faut structurer les informations en arbre, ce que les 3/4 des logiciels se configurant via XML ne font pas vraiment avec profit (ce que je dis là n'est pas propre aux applications java, c'est une tendance générale).
Il y a d'autres avantages:
-standard et donc partageable entre programmes.
-parser existant, pas besoin de se compliquer la vie.
-langages connexes pour manipuler ou transformer le fichier.
-DTD et schema pour assurer la validité du fichier.
Je suis d'accord, le XML c'est moche et c'est pénible de s'en taper à toutes les sauces dans les app java mais les frameworks qui s'en servent comme fichier de config ont de bonnes raisons.
Voilà, je reviens à la charge parce que j'ai d'autre question ....
quelqu'un a parler de plusieurs niveaux avec XML ...
Justement, ça m'intéresse ...
Par exemple, imaginons que je voudrais stocker dans mes paramètres une liste contenant ... heu ... des pays avec leur id.
Pour le moment, j'ai ça dans SQLite avec une table listPays avec dedans un champs id et un champs nomPays ...
Et voilà, XML pourrait-il m'être utile dans ce cas ?
Je ne voit pas trop comment utiliser les Properties, à moins de créer un fichier pour chaque liste (j'en ai pas mal) ...
Donc pensez-vous que XML pourrait me faire ça ?
Es-ce que XML est plus lourd que Properties ?
Voilà, je voulais juste savoir si XML vaudrait la chandelle dans ce cas ...
Faudrait que ce soit 2 fois plus rapide que SQLite parce que sinon SQLite est super pratique pour ça, mais c'est drôlement lourd, faut avouer ...
Mais j'imagine que XML doit être au moins 4 ou 5 fois plus rapide pour ne pas dire encore plus ... je me trompe ?
Merci.
EDIT
Citation : QuentinC 2
Ensuite, il y a les bases de données. C'est 100 fois plus lourd que XML, même SQLite, et on ne parle même pas de MySQL. Pour la config d'un programme, franchement, c'est lourd et ça ne sert à rien, soyons réalistes. Si on n'utilise déjà une base de données pour autre chose d'accord, mais sinon, ne sortons pas un tank pour abattre un moustique, c'est totalement contre-productif.
bon eh bien alors plus à hésiter ...
Je vais me renseigner, mais si vous savez comment faire ou avez des liens ...
Ouais, bon, à part dans le cas de front-end censé configurer des back-end, c'est pas très utile. ET même, il peuvent s'en sortir sans XML.
* -parser existant, pas besoin de se compliquer la vie.
En java, pour les properties aussi le parseur existe déjà d'office. Reste l'argument de la portabilité de langage certes... mais ça ne me paraît que moyennement utile, sauf si on est dans le premier cas évoqué juste ci-dessus.
* -langages connexes pour manipuler ou transformer le fichier.
Certes... mais XSLT aussi c'est lourd, et je ne vois pas trop en quoi il pourrait être utile dans le cadre de fichiers de configuration.
* -DTD et schema pour assurer la validité du fichier.
L'approche clé pas connue = j'ignore marche tout aussi bien amha.
Citation
Et voilà, XML pourrait-il m'être utile dans ce cas ?
Je ne voit pas trop comment utiliser les Properties, à moins de créer un fichier pour chaque liste (j'en ai pas mal) ...
C'est justement dans ce genre de cas que XML commence à devenir utile.
Mouais, parce que là, ma boîte de dialogue doit récupérer la liste de ces pays plus d'autre listes.
dans une boite ou je récupère 5 listes, ça prend 0.5 sec avec un ordi a plein régime comme le mien, mais pour le peu que l'ordi soit un peu surchargé, ça peu prendre jusqu'à quelques secondes ...
C'est beaucoup trop, avec XML, le problème est résolu ..
Une dernière question, es-ce que comme les properties, les paramètres se chargent au démarrage et ensuite marchent avec la mémoire vive ?
Ou es-ce que ça marche toujours avec la mémoire disque ?
En fait, il y a deux approches complètement différentes pour traiter du XML :
1° - On lit l'ensemble du fichier d'un seul coup et on crée une arborescence de noeuds facilement navigable et modifiable. C'est l'approche DOM, dont il existe une API standard en java (en l'occurence JDOM) comme dans pas mal d'autres langages dont javascript, php et C#.
Avantage: on peut manipuler le document comme un arbre, n'importe comment, et assez facilement (recherche, modification, ajout, suppression, déplacement de sous-arbre, etc.)
Inconvénient: ça consomme pas mal de mémoire et le chargement est relativement lent dès lors que la taille du fichier augmente, jusqu'à devenir inutilisable avec des fichiers de plus de quelques Mo.
2° - On ouvre le fichier et on le traite séquentiellement. Une fois qu'un élément a été traité, on ne peut pas revenir dessus. C'est l'approche XMLReader ou SAX, dont il existe aussi des implémentations standards en java (en l'occurence SAXParser), en php et en C#.
Avantage: le chargement est assez rapide, même avec des grosses bases de données de plusieurs Go (par contre je suis presque sûr que les properties restent quand même plus rapides à tailles de fichier égales puisque plus simples à parser).
Inconvénient: les éléments arrivent séquentiellement, donc on ne les traite qu'une fois sans plus y revenir ensuite. C'est plus difficile à manipuler, notamment pour regénérer un nouveau fichier avec des éléments modifiés, car il faut à chaque fois le refaire de zéro. Et si on veut une structure arborescente d'objets en mémoire, il faut la construire soi-même.
Si tu dois enregistrer plusieurs listes structurées, les properties commencent effectivement à devenir insuffisantes. Je te conseille de regarder du côté de JDOM d'abord, c'est le plus facile pour commencer.
D'accord ...
ça me dérange quand même un peu que JDOM ne soit pas plus puissant, mais bon ...
Au passage, ça ne me dérange pas de créer les fichier XML moi-même, je veux dire la structure.
Mais après, il faut que je puisse lire et modifier, ça c'est essentiel ... Après, la construction du fichier, je peu m'en occuper sans pb, d'ailleurs, ça irait plus vite à la main qu'avec JDom ! (pour coder mais aussi pour l'utilisateur).
Mais je n'ai pas compris quelque chose, c'est ta phrase qui revient plusieurs fois d'ailleurs :
Citation : QuentinC 2
Une fois qu'un élément a été traité, on ne peut pas revenir dessus
Heu ... ça veux dire quoi au juste ? qu'une fois un élément modifié (ou créé ?), tu ne peu pas le remodifier ? Et si on veux vraiment le remodifier, il faut fermer et rouvrir le fichier XML, c'est ça ? en gros, c'est combien de fois plus rapide que SQLite ?
Aussi, avec XML, les params sont travaillés en mémoire vive ou sur le disque directement ?
Bon, je pense que je vais utiliser XML ...
Merci beaucoup.
EDIT
Quelqu'un à parler de Xstream plus haut, je me renseigne dessus ...
Une fois qu'un élément a été traité, on ne peut pas revenir dessus
C'est le principe de l'approche séquentielle. Lorsque tu viens de lire l'élément n, tu ne peu lire QUE l'élément n+1. (pas de retour arrière , pas de saut "indexé").
Tu peu également ramener la tête de lecture au début du fichier (quelle chance !)
Si ton volume de données à traiter est important, reste sur SQLite, si il est faible, tu peut t'orienter vers une approche DOM.
D'accord, j'ai compris, pas de retour en arrière, comme la lecture des fichier en php ... sauf qu'en PHP on peu ramener le lecteur à telle ligne, mais bon, on n'est pas en PHP ...
c'est vrai, ça paraît fastidieux, je préfère quand même Jdom
Je me renseigne quand même sur Xstream.
Paramètres d'un prog, .ini, .properties ou bdd ?
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
"'But I don't want to go among mad people,' said Alice. 'Oh, you can't help that,' said the cat. 'We're all mad here.'" Lewis Carroll
"'But I don't want to go among mad people,' said Alice. 'Oh, you can't help that,' said the cat. 'We're all mad here.'" Lewis Carroll
"'But I don't want to go among mad people,' said Alice. 'Oh, you can't help that,' said the cat. 'We're all mad here.'" Lewis Carroll