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)