Discussion :

[maccormick]

Bonjour à tous,
Je travaille sur une application designée selon le pattern MVC. Tout fonctionne correctement mais je me pose la question suivante.
J'ai un traitement long à effectuer, mais qui ne nécessite pas d'être lancée dans une Thread différente de l'EDT car mon application est mono-threadée : l'utilisateur n'a pas le choix d'attendre la fin du traitement long
Ce traitement est lancé après un clic dans une JMenuBar, qui est une vue abonnée aux listeners de mon modèle via mon controleur.
Pour le traitement long, je veux utiliser une ProgressBar. Où dois-je la mettre pour respecter MVC ? Selon moi plusieurs choix :
1/ la vue s'occupe d'appeler la classe de traitement long et n'informe le contrôleur que quand le traitement est fini et qu'il y a quelque chose à fournir au modèle ? Ce cas me semble le plus simple car tout se passe en dehors du C et du M !
2/ la vue s'occupe juste de notifier au contrôleur que l'utilisateur a lancé le traitement long. Là j'ai des doutes : est-ce que le contrôleur n'informe le modèle qu'une fois que le traitement est fini et qu'il y a un résultat à transmettre au modèle pour le modifier ? Ou est-ce que le Contrôleur lance le traitement via un model.effectueTraitementLong ? Dans ce dernier cas, ça me semble une montagne pour respecter MVC car il faudrait que par exemple à chaque itération, le modèle informe par un fire() le contrôleur de ces changements, et que le contrôleur synchronise les vues, donc ma JProgressBar.

Merci de vos réponses "architecturales" !

[wax78]

Peut être trouveras tu réponse par ici :

http://rom.developpez.com/java-swingworker/
http://blog.developpez.com/adiguba/p...r_swingworkers

Sinon il te faudra un thread pour le process, et utiliser invokeLater sur tout ce qui concerne les changement de composants graphique.

[maccormick]

Non non, pas besoin de swingworkers justement, car mon appli est mono-thread, et les swingworkers j'en ai soupé ! Ma question est sur l'architecture à adopter pour la communication avec une ProgressBar dans une architecture MVC.

[wax78]

Sorry, j'ai dut mal te comprendre

[maccormick]

pas de soucis ... mais ça te dit rien ma question ?

[sinok]

Bah c'est simple, tu définis un modèle Task, qui a un compteur allant de un à cent et un statut par exemple. Modèle qui déclenche les évenements à chaque changement de compteur/statut.


Une TaskView qui contient ta JProgressBar et qui écoute ce qui ce passe dans ton modèle et réagit de façon accordée

Un TaskController qui gère le tout et effectue l'action longue (soit par une méthode ou par un Runnable).

Mais de toute façon, ta JProgressBar, dans une appli mono thread, je ne vois pas franchement l'intérêt. Elle ne bougera pas tant que la tâche longue ne se sera pas achevée si celle si implique des flux ou des algos bourrins.

[hwoarang]

J'ai un traitement long à effectuer, mais qui ne nécessite pas d'être lancée dans une Thread différente de l'EDT car mon application est mono-threadée : l'utilisateur n'a pas le choix d'attendre la fin du traitement long

Ce traitement est lancé après un clic dans une JMenuBar, qui est une vue abonnée aux listeners de mon modèle via mon controleur.
Pour le traitement long, je veux utiliser une ProgressBar.

Il me semble detecter une incohérence ici
Soit le traitement est fait dans l'EDT et il ne faut pas espérer mettre à jour l'ihm avant la fin (ce qui rend le progress bar inutile), soit il est fait hors de l'EDT, donc dans un autre thread...

[wax78]

Bah oui c'est ce que je pense depuis le début en fait... donc je ne suis pas fou

[maccormick]

bah oui en fait ! effectivement, dit comme ça, je détecte l'incohérence aussi ... bon, bah je vais faire mon traitement dans un autre thread ... c'est dommage de se compliquer la vie pour une cohérence conceptuelle native au langage !
merci et @+

[sinok]

bah oui en fait ! effectivement, dit comme ça, je détecte l'incohérence aussi ... bon, bah je vais faire mon traitement dans un autre thread ... c'est dommage de se compliquer la vie pour une cohérence conceptuelle native au langage !
merci et @+

En fait, ce n'est pas qu'en java que tu as ça. Mais sur quasiment tous les toolkits UI quels qu'ils soient...

En effet, il ne faut pas bloquer le thread de rendu, sinon, plus de rendu.