*view & *doc relationship

[Jacek Wojdel]

On Thu, 06 Apr 2000, you wrote:
> The point where I need help (and which could do with some examples in
> the documentation) is: Let's say the App class has a menu entry to
> change some data which opens a dialog. Who changes the document's data?
> Do I hand over a pointer or reference of the doc's data to the dialog
> which changes it? Does the dialog create some data and call a
> "doc->changeData(float xyz)"? Who looks after the update of the view
> after the data has been changed?

One of the things that I've learned on the lectures on OOP is that
hermetization is the Good Thing. That means that you shouldn't allow any class
to change document data except for document class itself. So protect your data
and publicize to the world methods that change it. That's the approach that you
suggest with calling "doc->changeData". It can be sometimes annoying and it
may seem easier just to make some data members public, but this approach really
pays back later.
For the second question, it all comes to having appropriate signal like:
document::dataChanged() connected to slot view::updateView() (as a matter of
fact, you could have also anotherView::updateView() connected to it, and
another, and another...) As any changes in the document cn be done only through
document class' methods, its relatively straightforward to put at the end of
each of those methods something like: "emit dataChanged()". There are of course
many issues like e.g. granularity of updates (if you change only one value in
a long table you probably shouldn't redraw the whole view), but this can be
achieved by passing appropriate values in signal like "emit dataChanged(
REDRAW_ALL, 0 )" or "emit dataChanged( REDRAW_SINGLE, i )". Take your time to
think this through and design it well or you'll end up rewriting things over
and over (like I do... I'm really bad in designing things :(.

> The doc-view model certainly has its merits, but it definitely
> complicates matters, so please help us novices!

And here we come to the most important point in my opinion. I've first met
doc-view model when learning MFC from some book. I've spent countless hours
struggling against some "features" of it (only half of them being a result of
MFC's awkwardness). After all this time I just realised that doc-view model is
only valid for DOCUMENT ORIENTED APPLICATIONS ! Pretty obvious, isn't it ?
Writting things like CDplayer or Master Mind game in doc-view framework is
(IMHO) simply just a lost of time. That I tried do do so in the past is again
an indication of how bad I am in designing.

Happy programming,
	Jacek

-- 
+-------------------------------------+
|from: J.C.Wojdel                     |
|      J.C.Wojdel at cs.tudelft.nl       |
+-------------------------------------+