*view & *doc relationship

[Erwin Rol]

The Document View pattern from MFC is a stripped down version of the
Model/View/Controler pattern as used in Smalltalk i believe.

The Model holds the information , the View "displays" the information,
and
the controler is resonsible for changing the information.
A Model itself can be a View of a other model again. A very good
reference is

Design Patterns - Elements ofReusable Object-Oriented Software
by Gamma, Helm, Johnson and Vlissides.

It also holds a lot of other design patterns that are realy worth
knowing and
using.

- Erwin




Tim Rohrer wrote:
> 
> Hauke,
> 
> >From what I've read, I think you want the doc class to manipulate the data.
> The user will cause the manipulation via interations with the view, but, the
> doc methods will make the actual changes and update files, etc. Perhaps someone
> else can confirm this for us?
> 
> I'm not quite as far along as you are.  My lack of understanding right now has
> to do with getting the data from the doc to the view.  Take the "simple" example
> of the html viewer.  I changed the base class for the view to KHTMLWidget.
> Now, I set a QString to point to an html file and create a new instance of
> KHTMLWidget in the App constructor.  Of course, to get it to view, I have to do
> a show() which creates a new window seperate from the main view.  I am not
> connecting the app, doc, and views.  Perhaps I shouldn't be creating the
> instance of KHTMLWidget in the App constructor but if I don't, how do I get the
> data in? Perhaps I'm mixing things up to much? I've been working my way through
> the tutorials and the kscribble example but maybe I need to go back to that and
> put more time into it.
> 
> I just noticed a couple more articles came in on this thread.  I'll give them a
> read.
> 
> Tks
> -tgr
> 
> On Thu, 06 Apr 2000, you wrote:
> > Hi, Tim!
> >
> > I have started working with C++ and kdevelop and - rest assured - the
> > document/view model was and still is confusing to me as well. The basic
> > idea
> > certainly is to separate the actual content of the document - text or
> > gif-files in your case - from their representation on the screen. So
> > your document class may contain a member variable of type QString
> > containing text or a list of pointers to gifs as well as methods for
> > saving and restoring this structure. The View class provides different
> > methods to show these contents on the screen - let' say a
> > "drawTextInCircularShape(const char* text)" function. You can open
> > different views of the same data with the document structure untouched -
> > e.g. a bar chart and a pie chart in the case of numerical data.
> >
> > 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?
> >
> > The doc-view model certainly has its merits, but it definitely
> > complicates matters, so please help us novices!
> >
> > Thanks, Hauke
> 
> --
> Tim Rohrer
> tgrohrer at metbymail.com
> http://www.metbymail.com/~rohrer

-- 
        Q - S O F T - E N G I N E E R I N G 
     Rodachtalweg 11, 81549 Muenchen, Germany

Erwin Rol (Software Engineer)     phone: +49-89-68050051
Erwin.Rol at Q-Soft-Engineering.com  fax  : +49-89-68050052