Multiple Views to a Model
Jason Cavett
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.
John B. Matthews
<b49ca42f-2ecc-4c65...@r15g2000prd.googlegroups.com>,
Jason Cavett <jason....@gmail.com> wrote:
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.
--
John B. Matthews
trashgod at gmail dot com
http://home.roadrunner.com/~jbmatthews/
Eric Sosman
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".
--
Eric Sosman
eso...@ieee-dot-org.invalid
John B. Matthews
Mark Space <mark...@sbcglobal.net> wrote:
> Jason Cavett wrote:
> > 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/>
John B. Matthews
r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> "John B. Matthews" <nos...@nospam.com> writes:
> >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/.
>
> »...«
>
> http://www.c2.com/cgi/wiki?FourLayerArchitecture
An excellent distinction. Thank you. I also enjoyed the nearby
discussion <http://www.c2.com/cgi/wiki?MvcIsNotObjectOriented>.
> 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.
Mark Space
> "John B. Matthews" <nos...@nospam.com> writes:
>>> http://www.c2.com/cgi/wiki?FourLayerArchitecture
>> An excellent distinction. Thank you. I also enjoyed the nearby
>> discussion <http://www.c2.com/cgi/wiki?MvcIsNotObjectOriented>.
>
> 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
>
I've been checking out Martin Fowler's work, who claims to have invented
split-model architecture.
<http://martinfowler.com/eaaDev/uiArchs.html>
Interesting read there. I haven't had a change to read the links in the
discussion yet, just tossing another idea out there. Thanks for the
discussion so far, the different application architectures are interesting.