responsibility of the C in MVC

[VisionSet]

In a Swing application the
Model is my separate business model
The View are the Swing components
The Controller consists of the event listeners

The controller is responsible for two types of action:

1/ To alter the model
2/ To alter the view by perhaps moving, adding, removing swing components or
otherwise manipulating the view of the model.

I can see that when 1/ occurs the Observer/Observable pattern comes into
play and the model notifies its registered observers (Swing components) who
take the appropriate action to update the view.

But I'm not clear on 2/.
When the view changes in my case I do not needlessly instantiate new
components I merely want them to point to different parts of the model. So
I update their attributes so they can ascertain this for themselves. Then
since there is a reference to the model held by the view an update triggered
by the event (2/) realigns the view with the model. No update to the model
has occured. The other option is to have the controller change the view as
decribed, and then manually trigger a notifyObservers by the model.

The general scheme of the gui is components of type A, B, C
A contains a number of B
B contains a number of C
I iterate through all of C by delegation from A through B to C.
Thus achieving updates of C, since C has the only real view of the model.

I haven't actually implemented the observer pattern yet, but I think I
understand the pertinent points, and its applicability.

Any comments?

 

[A. Craig West]

In a Swing application the
Model is my separate business model
The View are the Swing components
The Controller consists of the event listeners

The controller is responsible for two types of action:

1/ To alter the model
2/ To alter the view by perhaps moving, adding, removing swing components or
otherwise manipulating the view of the model.

I don't really consider altering the view to be part of the controllers job.
The controller is responsible for for altering the model. The view is
responsible for representing the model. When the controller alters the model,
the model would signal the view(s) that it has been altered. It doesn't seem
like a good idea to tie the implementation of the view and controller together,
except in those cases where they are the same class (Microsoft Document-View
comes to mind).

 

[VisionSet]

I don't really consider altering the view to be part of the controllers job.
The controller is responsible for for altering the model. The view is
responsible for representing the model. When the controller alters the model,
the model would signal the view(s) that it has been altered. It doesn't seem
like a good idea to tie the implementation of the view and controller together,
except in those cases where they are the same class (Microsoft Document-View
comes to mind).

Well perhaps it is just a case of terminology since clearly events will
drive the view on occasion when the model does not change. Whatever my
original query remains.