Re: mvc implementation


"sigmundo" wrote:
> hello,
>
> I wonder how to implemente
> a strict separation between
> view and controller.
> button are controller parts but
> there are components of view !

For a simple control like a button, this isn't much of a problem. Say
you have a button, the user clicks it and the button generates an event
in response. This event is sent to the controller part of the
application. The controller modifies the model and the model lets its
observers know that it has changed. One of those observers is the
button. The button may do nothing in response, or it may change the
display text, disable itself, or whatever. The way in which the button
displays itself is part of the view. The events it generates are sent to
the controller but the button does not contain any controller logic
itself.

Things get trickier with more complex controls depending on how the
control behaves. One problem I've had is with controls like combo boxes
that automatically update the way they are displayed in response to a
user event. For example, the user makes a selection from the combo box
and the combo box changes the displayed selected item. This can be
frustrating because the combo box is changing the view without waiting
for the model to be updated.

Suppose that the model is changed from a source outside of the combo box
and the combo box needs to be changed to stay in sync with the model.
Changing the selected item generates an event which is sent to the
controller. The controller then has to decide whether or not it is
necessary to change the model. In this case, it is not. But this has
just complicated things. Controls, in my opinion, need a strict
seperation of their view from the events they generate. Maybe some
widget libraries do this, but with Windows controls, I've run into this
problem more than once.


.