Discussion :

[RogerXXX]

Bonjour à tous
J'ai une IHM Swing qui utilise Flexdock comme framework de docking. On s'en sert pour permettre à l'utilisateur de découper sa fenêtre en tableaux de saisie.

Ca marche très bien mais là où ça se complique c'est qu'il va falloir faire persister l'état graphique de l'IHM. En effet notre appli comporte plusieurs fenêtres, et chacune peut comporter plusieurs onglets. C'est l'utilisateur qui ouvre ces fenêtres et ajoute ces onglets.
J'ai déjà eu du mal à persister l'état d'UN onglet dans UNE fenêtre, la fonctionnalité complète me semble inabordable.

En cherchant un peu sur le net je suis tombé sur la JSR296 qui gère la persistence du contexte IHM, et dont il existe un prototype. C'est la solution que je préfèrerais car les autres frameworks de docking n'ont pas l'air d'être trés au point pour la persistence, et la NetBeans Platform me semble compliquée (je connais pas, et le projet est développé en Eclipse).

Par contre je me demande si ça va bien se passer si je persiste le contexte IHM avec ce framework, sans passer par Flexdock. Est-ce qu'à la restauration on va bien retrouver nos billes?

Donc ma question est en deux parties:
- Est-ce qu'on peut espérer une version utilisable en projet du SwingAppFwk dans pas trop longtemps? Permettra-t-elle de gérer le docking, soit en interne soit en étant compatible avec une solution externe?
-Si on garde Flexdock, est-il possible de persister le contexte de notre appli multi-fenêtre et multi-onglets.

[xavlours]

Bonjour,

je ne connais pas trop flexdock, mais je crois que toute l'information sur le layout est contenue dans le LayoutNode obtenu par DockingPort#exportLayout. Il y a bien sûr l'inverse (importLayout).

Cette méthode m'a l'air assez sympa si on la couple avec de la sérialisation (ou de l'externalisation ou du XML). Il faut quand même vérifier si tout se passe bien (sérialisation récursive des LayoutNodes, des JComponents, etc), mais je crois que c'est un bon point de départ.