Sagewire Logo

MVC: how do I stop mutual recursion?

6 Message(s) by 5 Author(s) originally posted in java gui


From: Mungo Henning Date:   Sunday, September 23, 2007
Hi Folks,
Okays, although I'm not the oldest person here I'm struggling to understand
an issue in MVC
with a Swing JAVA application .
If someone could point me in the right direction I'd be obliged.

Here's the problem: I'm writing a little application and the idea of MVC
tickles me such that I
want to learn about it and implement it to fully appreciate MVC.
Hypothetically, if I have a plain "String" object in my model and a
"JTextField" object on my display, I
would software connect these by telling the Model when the end user changes
the text field, and using
the Observer pattern tell the JTextField (and any other viewers) when the
model data changes.

So if the end user types the first character in the JTextField then this
JTextField nudges the associated
Model and says "data has changed; you'd better update your String".
The model then updates its String object and then it has to tell ALL its
viewers that its data has changed.
These viewers include the originating JTextField, hence we get a mutual
loop: A calls B and then B calls A which
leads to A calling B again...

Knowing that others have solved this, how do people break this recursion?
I'd think that whomever informs the Model that the data has changed ought
not be on the list of Viewers that
the model should subsequently contact.

MVC sounds wonderful; someone enlighten my ignorance please.

Thanks in advance

Mungo :-)


From: Roedy Green Date:   Sunday, September 23, 2007
On Sun, 23 Sep 2007 18:29:37 +0100, "Mungo Henning" <mungoh@xxxxxxxxxxx>
wrote in message, quoted or indirectly quoted someone who said :

Knowing that others have solved this, how do people break this recursion?



I had a similar problem in JColourChooser. I simply created a boolean
called "propInProgress". When it was true, it suppressed propagation
of changes in a spreadsheet-like network of elements.

In a simple case, you can sometimes simply ignore or stop listening to
event s at A B when each is triggering unwanted changes in the other.
--
Roedy Green Canadian Mind Products
The JAVA Glossary
http://mindprod.com


From: Mungo Henning Date:   Sunday, September 23, 2007
Hi Roedy,
Obliged for your speedy reply.

On Sun, 23 Sep 2007 18:29:37 +0100, "Mungo Henning" <mungoh@xxxxxxxxxxx>
wrote in message, quoted or indirectly quoted someone who said :
Knowing that others have solved this, how do people break this recursion?
I had a similar problem in JColourChooser. I simply created a boolean
called "propInProgress". When it was true, it suppressed propagation
of changes in a spreadsheet-like network of elements.
In a simple case, you can sometimes simply ignore or stop listening to
events at A B when each is triggering unwanted changes in the other.



Hmmm... but that means that each side of the fence (well, at least one side
of the fence) has
to have extra code to break the spiral.
So the clean model of "when view changes, alert the model; when model
changes, alert all views" has to become
a little muddied.
Could there not be a case here to tweak the "observer" capability: when the
view tells the model that things have
changed the model responds to every other view EXCEPT the triggering view?

Just still trying to find the magic code that takes care of this for me...!

Regards

Mungo :-)


From: ram Date:   Sunday, September 23, 2007
"Mungo Henning" <mungoh@xxxxxxxxxxx> writes:
So the clean model of "when view changes, alert the model; when
model changes, alert all views" has to become a little muddied.



JAVA (Swing) doesn't use MVC.

In MVC, the view never notifies the model.

In MVC, the controller notifies the model.

In MVC, there is no loop, because the change initiated by a
user action flows from the controller to the model and then to
the view and then the flow has come to a halt - no loop.

I am aware of the problem you've posed,
but this has to do with Swing - not with MVC.

For Swing Architecture, see:

http://JAVA.sun.com/products/jfc/tsc/articles/architecture/

For MVC, see:

http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html


From: Filip Larsen Date:   Sunday, September 23, 2007
wrote in message

Knowing that others have solved this, how do people break this recursion?Two possible techniques is to either use a flag in the text field


listener to indicate an update is in progress and avoid changing the
text field if this flag is set, or to rely on all the models in use will
avoid emitting a change event if setting the same value as previously,
or both.

The first approach requires that you code it yourself, while the second
is support ed as standard by class es that use
JAVA.beans.PropertyChangeSupport for emitting change events.

If I recall correctly, not many swing models support suppression of
change events when the new value is "equal" to the old, so there you
basically has to use the first approach.Regards,
--
Filip Larsen


From: ralpe Date:   Monday, September 24, 2007
I solved this problem by creating my own text field class that derives
from JTextField and overrides the setText method. The overriden method
only invokes super.setText if the new string is different from
getText().

hth
ralph



Next Message: JTable (setForeground on text in cell)



Programming | Sports | Autos

copyright 2006
Valid XHTML 1.0 Transitional