Qt-interest Archive, September 2003
Re: [OT] Model, View, Controller question
Message 1 in thread
From: Derek Fountain [mailto:derekfountain@yahoo.co.uk]
> (...)
> The question goes a little deeper than just text widgets.
> For example, I have a listbox containing a list of filenames
> which can be added to, deleted from, and reordered using
> buttons on the GUI. At the moment I have the list of filenames
> stored in the model as well as in the listbox widget. When the
> buttons are clicked, signals are passed around to the model
> which updates it's structure, then signals the view to update.
> That seemed the correct way at the time, but it means
> duplication of data and hence possible inconsistency. Perhaps
> the view should look after the list and only pass the contents
> into the model when the model actually needs it?
>
> What's guidelines are there for this issue?
Hi Derek,
I am not an expert on MVC questions, so this answer is mainly based on intuition. The idea I see behind MVC is to make it easy to have multiple views (i.e. GUI representations) on the same model (i.e. the managed data). Given that, the answers to your questions would be:
1) If a view is a kind of dialog with "Apply", "Ok", and "Cancel" buttons, the model should be updated if and only if the apply or ok button is pressed. By this time the user confirms to 'propagate' the data.
2) If a view is not a dialog, but a standard GUI element, the model should be updated whenever it makes sense. "Making sense" here is synonymous for "being of interest for possible other views". An example: changing the line color of an object in one CAD view should simultaneously change the object's line color in all other CAD views.
3) If some data is specific for an individual view there is no need to update the model. For your listbox example this means: if the sorting order is only of interest to this individual listbox, there is no need to update the model. However, if the sorting order matters for the controller or other views (including other listboxes), the model has to be notified about the order changes.
Enough for theory, lets add some practical tips (you need not apply them ;-) :
a) for the first versions, try to keep your design and implementation as close to the theory as possible. That gives you the most flexibility. If (and only if) you run into performance problems you should search for possibilities for "delayed updates" where the model is updated later. Example: A QLineEdit does not need to update the model on every keystroke, it is sufficient to update when the line edit looses the focus.
b) for your listbox: maybe there is the possibility to derive from QListBoxItem and access the model data directly to circumvent data duplication. For example, by overloading paint() you may draw a string fetched from the model rather than one set for the item (maybe it is sufficient to overload text(), but this depends on the internals of the Qt source - I did not take a look at this).
Hope there were some useable ideas in my answer
Rainer
Message 2 in thread
On Friday 26 September 2003 14:23, Rainer Wiesenfarth wrote:
>If a view is not a dialog, but a standard GUI element, the model should
> be updated whenever it makes sense. "Making sense" here is synonymous for
> "being of interest for possible other views".
Absolutely right. I was starting to loose track of the basics here!
> Hope there were some useable ideas in my answer
Yes, there were. I concluded that Qt is plenty good enough to be used as a
data store. Where some data is held in a Qt widget, and it isn't used by
other views or the model in general, it seems OK to let the 'view' look after
the data.
I changed my code so that the listbox doesn't send signals to the controller
model each and every time a change is made. The model no longer stores the
information in that listbox. When the user hits the "do it" button, the view
signals the controller with all the information required which is held in the
view - the items of the listbox, the contents of the text widgets and so on.
The model gets to know what it needs to know, when it needs to know it, and
doesn't waster time trying to maintain a copy of what the QListBox is already
keeping track of quite happily. The code is simpler and makes more sense.
Thanks for your input, it was a great help! :o)
--
[ signature omitted ]
