[Interface Graphique/Java]Button et texte

[Premium]

Bonjour,

je voudrais savoir comment faire pour que ce qui est écrit dans un bouton et dans une zone de texte soit gardé en mémoire.

Par exemple si mon bouton et ma zone de texte sont vide, lorsque je ferme ma fenetre et relance le programme, ces 2 composants restent vides.

Si j'écris des trucs dedans, et que je relance le programme, ce que j'ai écrits doit toujours être là.

Comment on fait ça ?

Le truc, c'est que suivant que le champ texte et le bouton soit vide ou non, lorsque l'on clique dessus, le comportement est différent.

Si c'est vide, on a une fenetre permettant de taper un truc.

Si ce n'est pas vide, on modifie ou supprime le texte.

Quelles sont les méthodes qui permettent de savoir si un bouton ou une zone de texte est vide ou non ?

Merci

[Sentinel]

Une solution simple consiste à enregistrer un listener (de type WindowListener) auprès de ta fenêtre, de manière à pouvoir capturer l'événement "la fenêtre est fermée". Dans le code de gestion de cet événement, tu écris dans un fichier le contenu de ta zone de texte... Et au chargement du programme, tu relis ce fichier pour re-remplir la zone.

Pour savoir si une zone de texte est vide, appelle sa méthode getText(). N'oublie pas d'appliquer trim() également, pour supprimer les espaces éventuels.

[lorinc]

ou alors, tu sérializes ton bouton et ta zone de texte lorsque l'évennement quitter est enregistré, et tu désérialize - si possible - lors du lancement de l'appli...

[Sentinel]

Euh, et t'as pas encore plus crade comme méthode ?

[lorinc]

en Quoi c'est crade de sauvegarder une information contextuelle (liée aux instances des objets) en sérialisant les objets qui y sont liés ?

[pseudocode]

en Quoi c'est crade de sauvegarder une information contextuelle (liée aux instances des objets) en sérialisant les objets qui y sont liés ?

Ce n'est pas sale. C'est meme la solution la plus "orienté objet", car elle consiste a sauver un "etat" plutot que des valeurs d'attributs.

Mais comme la plupart des developpeurs (moi y compris) viennent de langage "procedural", genre C, ce n'est pas naturel. On prefere voir une classe comme un bon vieux "struct" et faire la sauvegarde/restauration des valeurs a la mimine.

plus d'info chez sun: http://java.sun.com/developer/technicalArt...g/serialization

[Sentinel]

Je suis parfaitement au courant du paradigme objet, merci.

Simplement, il est plus propre de sauver les valeurs significatives dans un format lisible, plutôt qu'une représentation binaire d'un objet complet. Un objet purement graphique (non-métier) qui plus est.

Si demain Premium souhaite mettre son texte dans un TextField plutôt qu'un TextArea, ou dans une toute autre structure, ce sera très facile s'il utilise ne sauvegarde que le texte. Il pourra également sauver/restaurer/transmettre les données facilement.

[lorinc]

oui, enfin t'es pas obligé de sérialiser dans un format binaire, il y a des solution lisibles à base de xml qui existent :

http://xstream.codehaus.org/index.html

http://www.wutka.com/jox.html

http://koala.ilog.fr/XML/serialization/

francehment, c'est plus pratique et plus intuitif que simplement sauvegarder le texte, soit dans un fichier texte, et donc de se taper la conception d'une grammaire, soit dans un xml, et donc se taper la conception d'un DOM, alors que des bibliothèque le font très bien toute seule

[Sentinel]

Mais il ne veut pas sauver des données complexes, juste le contenu de sa zone de texte... Je ne vois pas ce vient faire une grammaire là-dedans !!!

[Premium]

En faite, il me faudra garder en mémoire plusieurs éléments.

Je n'ai pas bien saisie les différentes techniques proposées.

Est-ce que quelqu'un pourrait m'indiquer un exemple ?

Merci

[Sentinel]

Du plus crade au plus propre :

1. Tu sérialises tes objets (JButton, etc) dans un fichier. Ce sont donc les images mémoire (je simplifie) de ces objets qui sont écrites sur disque.

Inconvénients :

- Tes données seront illisibles avec un éditeur simple.

- Les données sont liées à une représentation graphique particulière, ce qui exclut un changement simple de réprésentation (si tu veux présenter le texte dans un JTextField au lieu d'un JTextArea par exemple).

2. Tu crées un objet spécialisé dont le rôle est de garder les données de ton application, et seulement les données. Ensuite, tu sérialises cet objet dans un fichier.

Inconvénient : format binaire comme au-dessus, mais au moins tes données sont indépendantes de leur moyen d'affichage. L'interface de ton application pourra évoluer sans compromettre la pérénnité de tes données.

3. Tu crées un objet spécialisé, et tu écris des fonctions pour le sauver/charger sous forme de texte lisible.

Inconvénient : il faut que tu décides de la manière dont les données seront écrites dans le fichier : quel ordre, quel format...

Avantage : Les données sont lisibles "en clair". Cela te permet de les lire, les éditer, les sauvegarder facilement, même si ton application disparaît un jour ou subit d'importantes modifications.

4. Tu crées un objet spécialisé, et tu utilises des librairies pour le sauvegarder sous forme de XML.

Avantages : c'est du texte clair, les données sont auto-documentées, et en plus elles peuvent présenter une structure hiérarchique.

Inconvénients : Tu dois intégrer et apprendre à te servir d'outils plus ou moins complexes, c'est peut-être exagéré par rapport à ton besoin réel. Et, comme le XML est une langage de balisage, le fichier peut être beaucoup plus gros qu'un fichier texte "classique".

5. Outsider : intégrer une base de données dans ton application. Tu peux utiliser HsqlDB, Derby, etc... qui sont écrites en java et étudiées pour être embarquées dans les applications.

Avantages : bases de données :)

Inconvénients : sûrement "overkill" par rapport à ton besoin, si ton volume de données est faible.