Question sérialisation / transient

Salut,

Je me pose une question... donc je vous en fait part :)

Imaginons une application composée d'un modèle et d'une vue (/controlleur).
Le modèle contient des objets de type EventListenerList de manière à pouvoir être écouté.

Supposons que nous souhaitons proposer 2 services par sérialisation :
- sérialiser tout le modèle pour le stocker dans un fichier ;
- sérialiser toute l'application pour récupérer l'état "actuel" par désérialisation.

Si on déclare EventListenerList transient, on ne peut pas réaliser le 2e service.
Si on ne le déclare pas transient, le premier service ne donnera pas uniquement le modèle... mais également les vues qui l'observent...

Comment faire alors?

Une solution à laquelle je pense, c'est lors de la sérialisation du modèle uniquement, virer tous les écouteurs, sérialiser, et remettre tous les écouteurs... Mais cela entraîne des problèmes de visibilité (il ne faut pas pouvoir virer tous les écouteurs de l'extérieur).

Avez-vous une idée?

NB: ce n'est pas une application à réaliser, c'est juste pour la "conception théorique".

Ah je viens de penser à une autre solution...
Déclarer EventListenerList transient, et redéfinir writeObject() et readObject(), writeObject() sérialisant ou non les écouteurs selon un flag indiquant s'ils doivent être sérialisés...

La sérialisation objets graphique swing est expressément déconseillée dans le JDK. Par exemple, pour JComponent, dans le javadoc :

Citation:

---

Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeansTM has been added to the java.beans package. Please see XMLEncoder.

---

Voilà, c'est clair : Please see XMLEncoder.

Evidemment, des fois, on n'est pas please. La solution que j'adopte en ce cas se rapproche des visuels super-légers avec des modèles intermédiaires très proches des propos du visuel, mais sans visuel. Donc je ne sérialise toujours pas le visuel, seulement un modèle du visuel, avec, bien sûr, toujours le modèle métier quelque part.

Ce sont des idées qui tournent au niveau du pattern MVP (modèle / vue / présentation) et de la problématique de test des GUI. Tu peux t'inspirer de GUI Architectures. Des idées sont à piocher aussi dans le modèle Présentation, Abstraction, Contrôle.

Citation:

---

Envoyé par spekal

La sérialisation objets graphique swing est expressément déconseillée dans le JDK. Par exemple, pour JComponent, dans le javadoc :

Voilà, c'est clair : Please see XMLEncoder.

Evidemment, des fois, on n'est pas please. La solution que j'adopte en ce cas se rapproche des visuels super-légers avec des modèles intermédiaires très proches des propos du visuel, mais sans visuel. Donc je ne sérialise toujours pas le visuel, seulement un modèle du visuel, avec, bien sûr, toujours le modèle métier quelque part.

Ce sont des idées qui tournent au niveau du pattern MVP (modèle / vue / présentation) et de la problématique de test des GUI. Tu peux t'inspirer de GUI Architectures. Des idées sont à piocher aussi dans le modèle Présentation, Abstraction, Contrôle.

---

Merci de ta réponse, très intéressant...

Donc si dans une appli, on ne veut pas d'ihm sérialisée mais seulement le modèle, on est obligé de déclarer tous les EventListenerList transient?

(Pour XMLEncoder, c'est juste pour les JavaBeans, ce qui n'est pas forcément la représentation du modèle)

Citation:

---

Envoyé par ®om

Merci de ta réponse, très intéressant...

Donc si dans une appli, on ne veut pas d'ihm sérialisée mais seulement le modèle, on est obligé de déclarer tous les EventListenerList transient?

---

À ce niveau, à ma connaissance, chacun fait sa petite cuisine. Perso je n'aime pas du tout sérializer la liste des listeners, parce que je considère que cela revient de proche en proche à sérialiser toute l'appli, donc, à se heurter, à un moment ou à un autre, à des impossibilités. (c'est comme ça, je pense, que l'on voit quelques fois apparaître sur le forum des questions style Comment je fais pour sérialiser mes threads ?...)

Il me semble qu'il faut considérer que la déserialization passe par une phase de reconstruction des objets, reconstruction au cours de laquelle on ré-organise leurs relations ; et, en particulier, on replace les listeners aux bons endroits.

Citation:

---

Envoyé par ®om

(Pour XMLEncoder, c'est juste pour les JavaBeans, ce qui n'est pas forcément la représentation du modèle)

---

Ah ?




... pour une réponse un peu plus constructive :D (excuse-moi, j'adore les réponses alambiquées :D ), je te signale que tu peux complètement configurer la sérialisation par XMLEncoder de n'importe quelle classe. Par exemple dans le jdk il y a déjà le XMLEncoder des listes en plus de celle des beans.

Citation:

---

Envoyé par spekal

... pour une réponse un peu plus constructive :D (excuse-moi, j'adore les réponses alambiquées :D ), je te signale que tu peux complètement configurer la sérialisation par XMLEncoder de n'importe quelle classe. Par exemple dans le jdk il y a déjà le XMLEncoder des listes en plus de celle des beans.

---

Je te répondais ça car dans la doc de XMLEncoder:

Citation:

---

Despite the similarity of their APIs, the XMLEncoder class is exclusively designed for the purpose of archiving graphs of JavaBeans as textual representations of their public properties. Like Java source files, documents written this way have a natural immunity to changes in the implementations of the classes involved. The ObjectOutputStream continues to be recommended for interprocess communication and general purpose serialization.

---

Après, je ne connais pas (encore) trop ce monde de JavaBeans...

Oui oui oui tu as raison, mais il y a des exceptions qui confirment la règle, sinon ce ne serait pas drôle... les exceptions sont les types simples (du moins leur version objet), et les listes... Vois tout ce qui tourne autour du java.beans.PersistanceDelegate si je sujet t'interrese.