Apres avoir bien étudié la théorie sur la construction d'IHM basé sur MVC,
je tombe sur un point qui me bloque.
J'ai en effet bien compris l'articulation entre les differentes parties du
MVC avec le principe d'observable/observer .... (ou subscribe/notify).
Imaginons que j'ai une fenetre en java, disons une grosse Jpanel, contenant
d'autres Jpanels (pour simplifier 2, jpanel 1, jpanel2)
De plus jpanel 1 cotient 2 autres jpanels, nommé jpanel 11 et jpanel 12.
En l'etat actuel des choses, j'ai une class Toto () qui represente mon
"model", c'est a dire que toto contient toutes les infos de ma fenetre.
de plus j'ai séparé les actionListeners (control) ... Donc c très chouette
car là j'ai du MVC nikel, tout bien séparé.
Mon MVc marche bien car si jamais pour une raison quelconque Toto est
modifié (je le repere avec les setter) j'envoie une notification a ma
fenetre et elle se rafraichi ... sic ...
Seulement voila, imaginons que ma fenetre contient bcp de petits Jtext
affichant chacune un attribut de Toto(), lorsqu'un attribut de Toto change,
alors il va envoyer une notification a ma grosse fenetre qui va TOUT
rafraichir ... Ce qui veut dire tout reafficher pour juste 1 petit attribut
de changer ....
Je cherche donc une amelioration a ce systeme qui me permettrait de
réafficher seulement ce qui est nécessaire
J'ai commencé à explorer plusieurs pistes :
1) J'ai 3 Jpanels donc on peut penser qu'on peux diviser Toto en 3 parties,
ce qui donne 3 models servant 3 vues ... 1 model qui change ne notifie
qu'une vue ... ainsi le rafraichissement est local ....
je trouve ca bof, d'autant plus qu'il faut separer Toto, et on en a pas
forcement envie ...
2) je garde Toto entier, j'ai finalement 3 Jpanels donc 3 vues. Ces 3
petites vue référenci le model Toto toute les 3, mais ne represente chacune
qu'une partie de Toto ... PROB : qd Toto est modif, selon le principe MVC il
notifie toutes les Vue du model, donc notifie les 3 vues, qui vont donc se
rafraichir les 3 (( que faire ?
-> j'ai penser à un truc pas tres objet: je garde ce mecanisme et qd je
notifie je passe en parametre un int qui specifie que Jpanel est concerné
... (bof bof hein ?)
3) ???? A vous
meric bcp
begin 666 icon_sad.gif
M1TE&.#EA#P`/`+,,`/_J`$5%10```/_.`/_)`/Z=`/^T`/_^D__]$___Q__E
M`/__ZP```````````````"'Y! $```P`+ `````/``\```18D$D9:IV8U97.
M&1<6< @"G$,13$$GG+"0KMKQPC&H)29P^R>"*G#H_6X$0^6 :P*2E9XSJ P,
DIB>%<&4]";[?ITXS&/P`"IF*52:XW;-,Q4 W##,L"VT2`0`[
`
end
begin 666 icon_wink.gif
M1TE&.#EA#P`/`+,,`/_J`$5%10```/_.`/_)`/Z=`/^T`/_^D__]$___Q__E
M`/__ZP```````````````"'Y! $```P`+ `````/``\```17D$D9:IV8U97.
M&1<6< @"G$,13$$GG#"0KMKQQC"H)29P^R^"*G#H_6 $0^6 PR4KO690&1@T
C3P*%<%7UQ8(ZS6"@$)BSA!EK3&BWU:* 86X89E@6VB0"`#L`
`
end
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas Delsaux
Le 17.10 2003, "Nosnos" s'est levé(e) et s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"
Apres avoir bien étudié la théorie sur la construction d'IHM basé sur MVC, je tombe sur un point qui me bloque.
Accroches-toi, ça va décoller ;-)
Mon MVc marche bien car si jamais pour une raison quelconque Toto est modifié (je le repere avec les setter) j'envoie une notification a ma fenetre et elle se rafraichi ... sic ...
Quel type d'événement est utilisé pour ce rafraîchissement ? Au pif, je parie que tu appelles directement la méthode repaint de tes JPanel.
Je cherche donc une amelioration a ce systeme qui me permettrait de réafficher seulement ce qui est nécessaire
J'ai commencé à explorer plusieurs pistes : 1) J'ai 3 Jpanels donc on peut penser qu'on peux diviser Toto en 3 parties, ce qui donne 3 models servant 3 vues ... 1 model qui change ne notifie qu'une vue ... ainsi le rafraichissement est local .... je trouve ca bof, d'autant plus qu'il faut separer Toto, et on en a pas forcement envie ...
Tout à fait. Ce n'est pas le modèle qui doit ss'adapter aux vuies (car théoriquement il n'a aucune conscience de ces vues) mais le contraire.
2) je garde Toto entier, j'ai finalement 3 Jpanels donc 3 vues. Ces 3 petites vue référenci le model Toto toute les 3, mais ne represente chacune qu'une partie de Toto ... PROB : qd Toto est modif, selon le principe MVC il notifie toutes les Vue du model, donc notifie les 3 vues, qui vont donc se rafraichir les 3 (( que faire ? -> j'ai penser à un truc pas tres objet: je garde ce mecanisme et qd je notifie je passe en parametre un int qui specifie que Jpanel est concerné ... (bof bof hein ?) 3) ???? A vous
Merci. Donc, ton modèle doit notifier les vues. As-tu pensé à utiliser les PropertyChangeListener, event, ... Bien que ces propriétés soient définies dans le package java.beans, il me semble que c'est le bon moyen pour ton modèle de notifier les vues. Supposons que ta vue 1 contienne une représentation de l'attribut a de Toto, et que ta vue 2 contienne une représentation de l'attribut b de Toto. Tes deux vues sont des PropertyChangeListener qui se sont enregistrées auprès de Toto. Lorsque la valeur de a change, Toto envoie uin PropertyChangeEvent à toutes les vues et seule 1, qui contient une représentation de a, change, car elle "sait" qu'elle contient cette représentation. Comment faire ça ? Là, je te laisse seul juge ...
meric bcp
-- Nicolas Delsaux "L'humour est une chose trop sérieuse pour être confiée aux rigolos." Marcel Gotlib
Le 17.10 2003, "Nosnos" <nosnos94@wanadoo.fr> s'est levé(e) et s'est dit
"tiens, je vais écrire aux mecs de fr.comp.lang.java"
Apres avoir bien étudié la théorie sur la construction d'IHM basé sur
MVC, je tombe sur un point qui me bloque.
Accroches-toi, ça va décoller ;-)
Mon MVc marche bien car si jamais pour une raison quelconque Toto est
modifié (je le repere avec les setter) j'envoie une notification a ma
fenetre et elle se rafraichi ... sic ...
Quel type d'événement est utilisé pour ce rafraîchissement ?
Au pif, je parie que tu appelles directement la méthode repaint de tes
JPanel.
Je cherche donc une amelioration a ce systeme qui me permettrait de
réafficher seulement ce qui est nécessaire
J'ai commencé à explorer plusieurs pistes :
1) J'ai 3 Jpanels donc on peut penser qu'on peux diviser Toto en 3
parties, ce qui donne 3 models servant 3 vues ... 1 model qui change
ne notifie qu'une vue ... ainsi le rafraichissement est local ....
je trouve ca bof, d'autant plus qu'il faut separer Toto, et on en a
pas forcement envie ...
Tout à fait. Ce n'est pas le modèle qui doit ss'adapter aux vuies (car
théoriquement il n'a aucune conscience de ces vues) mais le contraire.
2) je garde Toto entier, j'ai finalement 3 Jpanels donc 3 vues. Ces 3
petites vue référenci le model Toto toute les 3, mais ne represente
chacune qu'une partie de Toto ... PROB : qd Toto est modif, selon le
principe MVC il notifie toutes les Vue du model, donc notifie les 3
vues, qui vont donc se rafraichir les 3 (( que faire ?
-> j'ai penser à un truc pas tres objet: je garde ce mecanisme et qd
je notifie je passe en parametre un int qui specifie que Jpanel est
concerné ... (bof bof hein ?)
3) ???? A vous
Merci.
Donc, ton modèle doit notifier les vues. As-tu pensé à utiliser les
PropertyChangeListener, event, ...
Bien que ces propriétés soient définies dans le package java.beans, il me
semble que c'est le bon moyen pour ton modèle de notifier les vues.
Supposons que ta vue 1 contienne une représentation de l'attribut a de
Toto, et que ta vue 2 contienne une représentation de l'attribut b de
Toto.
Tes deux vues sont des PropertyChangeListener qui se sont enregistrées
auprès de Toto.
Lorsque la valeur de a change, Toto envoie uin PropertyChangeEvent à
toutes les vues et seule 1, qui contient une représentation de a, change,
car elle "sait" qu'elle contient cette représentation. Comment faire ça ?
Là, je te laisse seul juge ...
meric bcp
--
Nicolas Delsaux
"L'humour est une chose trop sérieuse pour être confiée aux rigolos."
Marcel Gotlib
Le 17.10 2003, "Nosnos" s'est levé(e) et s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"
Apres avoir bien étudié la théorie sur la construction d'IHM basé sur MVC, je tombe sur un point qui me bloque.
Accroches-toi, ça va décoller ;-)
Mon MVc marche bien car si jamais pour une raison quelconque Toto est modifié (je le repere avec les setter) j'envoie une notification a ma fenetre et elle se rafraichi ... sic ...
Quel type d'événement est utilisé pour ce rafraîchissement ? Au pif, je parie que tu appelles directement la méthode repaint de tes JPanel.
Je cherche donc une amelioration a ce systeme qui me permettrait de réafficher seulement ce qui est nécessaire
J'ai commencé à explorer plusieurs pistes : 1) J'ai 3 Jpanels donc on peut penser qu'on peux diviser Toto en 3 parties, ce qui donne 3 models servant 3 vues ... 1 model qui change ne notifie qu'une vue ... ainsi le rafraichissement est local .... je trouve ca bof, d'autant plus qu'il faut separer Toto, et on en a pas forcement envie ...
Tout à fait. Ce n'est pas le modèle qui doit ss'adapter aux vuies (car théoriquement il n'a aucune conscience de ces vues) mais le contraire.
2) je garde Toto entier, j'ai finalement 3 Jpanels donc 3 vues. Ces 3 petites vue référenci le model Toto toute les 3, mais ne represente chacune qu'une partie de Toto ... PROB : qd Toto est modif, selon le principe MVC il notifie toutes les Vue du model, donc notifie les 3 vues, qui vont donc se rafraichir les 3 (( que faire ? -> j'ai penser à un truc pas tres objet: je garde ce mecanisme et qd je notifie je passe en parametre un int qui specifie que Jpanel est concerné ... (bof bof hein ?) 3) ???? A vous
Merci. Donc, ton modèle doit notifier les vues. As-tu pensé à utiliser les PropertyChangeListener, event, ... Bien que ces propriétés soient définies dans le package java.beans, il me semble que c'est le bon moyen pour ton modèle de notifier les vues. Supposons que ta vue 1 contienne une représentation de l'attribut a de Toto, et que ta vue 2 contienne une représentation de l'attribut b de Toto. Tes deux vues sont des PropertyChangeListener qui se sont enregistrées auprès de Toto. Lorsque la valeur de a change, Toto envoie uin PropertyChangeEvent à toutes les vues et seule 1, qui contient une représentation de a, change, car elle "sait" qu'elle contient cette représentation. Comment faire ça ? Là, je te laisse seul juge ...
meric bcp
-- Nicolas Delsaux "L'humour est une chose trop sérieuse pour être confiée aux rigolos." Marcel Gotlib
Nosnos
Merci. Donc, ton modèle doit notifier les vues. As-tu pensé à utiliser les PropertyChangeListener, event, ... Bien que ces propriétés soient définies dans le package java.beans, il me semble que c'est le bon moyen pour ton modèle de notifier les vues. Supposons que ta vue 1 contienne une représentation de l'attribut a de Toto, et que ta vue 2 contienne une représentation de l'attribut b de Toto. Tes deux vues sont des PropertyChangeListener qui se sont enregistrées auprès de Toto. Lorsque la valeur de a change, Toto envoie uin PropertyChangeEvent à toutes les vues et seule 1, qui contient une représentation de a, change, car elle "sait" qu'elle contient cette représentation. Comment faire ça ? Là, je te laisse seul juge ...
Et bien justement, c'est la mon souci, je ne sais pas comment faire ca. Je ne vois pas comment est ce que la vue qui contient la representation va elle se rafraichir et les autre non, etant donnée que si un attribut de Toto change c Toto tout entier qui notifie tt les vues, et par consequent toutes les vues auront tendance a se rafraichir ....
tu pourrais pas me debloquer ?
merci
Merci.
Donc, ton modèle doit notifier les vues. As-tu pensé à utiliser les
PropertyChangeListener, event, ...
Bien que ces propriétés soient définies dans le package java.beans, il me
semble que c'est le bon moyen pour ton modèle de notifier les vues.
Supposons que ta vue 1 contienne une représentation de l'attribut a de
Toto, et que ta vue 2 contienne une représentation de l'attribut b de
Toto.
Tes deux vues sont des PropertyChangeListener qui se sont enregistrées
auprès de Toto.
Lorsque la valeur de a change, Toto envoie uin PropertyChangeEvent à
toutes les vues et seule 1, qui contient une représentation de a, change,
car elle "sait" qu'elle contient cette représentation. Comment faire ça ?
Là, je te laisse seul juge ...
Et bien justement, c'est la mon souci, je ne sais pas comment faire ca. Je
ne vois pas comment est ce que la vue qui contient la representation va elle
se rafraichir et les autre non, etant donnée que si un attribut de Toto
change c Toto tout entier qui notifie tt les vues, et par consequent toutes
les vues auront tendance a se rafraichir ....
Merci. Donc, ton modèle doit notifier les vues. As-tu pensé à utiliser les PropertyChangeListener, event, ... Bien que ces propriétés soient définies dans le package java.beans, il me semble que c'est le bon moyen pour ton modèle de notifier les vues. Supposons que ta vue 1 contienne une représentation de l'attribut a de Toto, et que ta vue 2 contienne une représentation de l'attribut b de Toto. Tes deux vues sont des PropertyChangeListener qui se sont enregistrées auprès de Toto. Lorsque la valeur de a change, Toto envoie uin PropertyChangeEvent à toutes les vues et seule 1, qui contient une représentation de a, change, car elle "sait" qu'elle contient cette représentation. Comment faire ça ? Là, je te laisse seul juge ...
Et bien justement, c'est la mon souci, je ne sais pas comment faire ca. Je ne vois pas comment est ce que la vue qui contient la representation va elle se rafraichir et les autre non, etant donnée que si un attribut de Toto change c Toto tout entier qui notifie tt les vues, et par consequent toutes les vues auront tendance a se rafraichir ....
