Multiple Views to a Model

[Jason Cavett]

I was wondering if anybody here has implemented multiple (Swing) views
to a common model.

I'm currently doing this, and I'm having an issue where

1. I update the model via the first view (type some text into a text
box)
2. a listener on the text box sets the data in the model
3. the model fires a notification (per Observer pattern) because its
data has changed and
4. the second view is updated.

However, when the fields in the second view are updated, THEIR own
listeners fire off and the underlying model is set again, and proceeds
to repeat the above sequence (but flipped for the views) so the GUI
falls into an infinite loop.

Has anybody ever run into this issue before? How did you handle it?
(For now, I have a flag checking to see if the notification should be
fired or not, but it's not very robust or extendable and is causing
its own set of problems.)

I'm open to suggestions. Thanks!

 

[Mark Space]

I was wondering if anybody here has implemented multiple (Swing) views
to a common model.

It seems to me you need two sets of update methods. One set faces the
user, and fires update messages when the user updates. The second set
faces the controller/model, and takes updates, but does not fire change
events.

That way user actions cause updates to all views, but changes to the
model by itself does not. Seems the only way to break loop.


Customer -> UpdateV -> ViewModel -> fires change notification
does not fire listeners <- ViewModel <- UpdateM <- Model/Controller

I'd be interested to hear if anyone has some specific suggestions, I've
never tackled this exact problem either.

 

[Stefan Ram]

However, when the fields in the second view are updated, THEIR own
listeners fire off and the underlying model is set again

There should be two different methods:

- The /model/ change listener method of the second view
reads from the model and writes to the view. It does
/not/ fire.

- The /user edit/ change listener method of the second
view /does/ fire.

Possibly, it might help to use two different verbs for
these two different means of modification, like:

- »modify_field()« and

- »change_field()« or so.

 

[John B. Matthews]

I was wondering if anybody here has implemented multiple (Swing) views
to a common model.

I'm currently doing this, and I'm having an issue where

1. I update the model via the first view (type some text into a text
box)
2. a listener on the text box sets the data in the model
3. the model fires a notification (per Observer pattern) because its
data has changed and
4. the second view is updated.

However, when the fields in the second view are updated, THEIR own
listeners fire off and the underlying model is set again, and proceeds
to repeat the above sequence (but flipped for the views) so the GUI
falls into an infinite loop.

Has anybody ever run into this issue before? How did you handle it?
(For now, I have a flag checking to see if the notification should be
fired or not, but it's not very robust or extendable and is causing
its own set of problems.)

I'm open to suggestions. Thanks!

It sound like you have two views, each trying to be the controller.

In the Design section of this example,

<http://robotchase.sourceforge.net/>

one can see that the single controller instantiates a model and three
views:

<http://robotchase.svn.sourceforge.net/viewvc/robotchase/trunk/src/org/gc
s/robot/RobotChase.java?revision=42&view=markup>

As designed, only the controller was permitted to change the model's
state; the views were "read-only" with respect to the model.

Later as a convenience, the RCInfo view was delegated authority to
change the game's state on behalf of the controller in response to
mouseClicked events:

<http://robotchase.svn.sourceforge.net/viewvc/robotchase/trunk/src/org/gc
s/robot/RCInfo.java?revision=34&view=markup>

It was a simple matter to re-factor and overload the only legitimate
command in that setting, move(). In effect, if you have more than one
controller, you have to keep them straight.

I look forward to your code example.

 

[Eric Sosman]

I was wondering if anybody here has implemented multiple (Swing) views
to a common model.

I'm currently doing this, and I'm having an issue where

1. I update the model via the first view (type some text into a text
box)
2. a listener on the text box sets the data in the model
3. the model fires a notification (per Observer pattern) because its
data has changed and
4. the second view is updated.

However, when the fields in the second view are updated, THEIR own
listeners fire off and the underlying model is set again, and proceeds
to repeat the above sequence (but flipped for the views) so the GUI
falls into an infinite loop.

Has anybody ever run into this issue before? How did you handle it?
(For now, I have a flag checking to see if the notification should be
fired or not, but it's not very robust or extendable and is causing
its own set of problems.)

I'm open to suggestions. Thanks!

The model should check whether the change is really a
change. It should fire change notifications if "Hello"
changes to "World", but not if it changes (ahem) to "Hello".

 

[John B. Matthews]

I was wondering if anybody here has implemented multiple (Swing)
views to a common model.

[thoughtful approach]

I'd be interested to hear if anyone has some specific suggestions,
I've never tackled this exact problem either.

FWIW, I often refer to this article:

<http://en.wikipedia.org/wiki/Model-view-controller>

But I like this picture better:

<http://java.sun.com/blueprints/patterns/images/mvc-structure-generic.gif>

In particular, it suggests that a view should read the model but not
change it; user gestures should go through the controller. Both the OP's
and my example allow a view to change the model's state directly. It's
not forbidden, but the model has to account for the change just as the
controller would have done (IIUC, as you, Stefan and Eric proposed).

This article details how Swing uses the MVC pattern:

<http://java.sun.com/products/jfc/tsc/articles/architecture/>

 

[Stefan Ram]

In particular, it suggests that a view should read the model but not
change it; user gestures should go through the controller.

In order to discuss finer details, possibly, one needs to
tell the /application model/ from the /domain model/.

»The ApplicationModel layer. This layer mediates between
the various user interface components on a GUI screen and
translates the messages that they understand into messages
understood by the objects in the domain model. It is
responsible for the flow of the application and controls
navigation from window to window. This layer is often
partially generated by a window-builder and partially
coded by the developer.«

http://www.c2.com/cgi/wiki?FourLayerArchitecture

One approach might favor a stateless view and controller: All
the state would be in a model. In this case, possibly a view
might have some reason to change the application model, but
never the domain model.

 

[John B. Matthews]

In order to discuss finer details, possibly, one needs to
tell the /application model/ from the /domain model/.

»...«

http://www.c2.com/cgi/wiki?FourLayerArchitecture

An excellent distinction. Thank you. I also enjoyed the nearby

One approach might favor a stateless view and controller: All
the state would be in a model. In this case, possibly a view
might have some reason to change the application model, but
never the domain model.

Yes. IIUC, using this example,

<http://sites.google.com/site/drjohnbmatthews/kineticmodel>,

the Assembly of Particle(s) (which manipulate vectors) is the
DomainModel layer, while the ControlPanel (which governs user settings)
maintains the ApplicationModel layer.

 

[Stefan Ram]

An excellent distinction. Thank you. I also enjoyed the nearby
discussion <http://www.c2.com/cgi/wiki?MvcIsNotObjectOriented>.

I found the above page on FourLayerArchitecture via another
document that was written by Trygve Reenskaug himself (the man
usually attributed with the invention of MVC), namely

http://heim.ifi.uio.no/trygver/2003/javazone-jaoo/MVC_pattern.pdf

. So, when Trygve Reenskaug mentions it, it seems somewhat
authoritative (or, at least: relevant) to me.

I also know of another source, which says that this
distinction is the traditional way to implement MVC:

»Traditional MVC implementations have further split
the Model into Domain Models and Application Models«

http://www.mimuw.edu.pl/~sl/teaching/00_01/Delfin_EC/Overviews/MVC.htm