From: Chris Gehlker <gehlker@...>
Date: 2002-07-25T11:42:02+09:00
Subject: Re: GUI's and the Rouge, Part III (yes, finally) 1/2

On 7/24/02 1:26 PM, "Tom Sawyer" <transami@transami.net> wrote:

> On Wed, 2002-07-24 at 12:07, Massimiliano Mirra wrote:
>> Tom is not talking about bolting a GUI onto an *application*, he's
>> talking about bolting a GUI onto a *model*, i.e. a set of classes that
>> describe program logic and are ignorant of user interfaces.
> 
> hi Massimiliano,
> 
> i've just finished reading up on MVC. but i'm little puzzeled about how
> the paradigm i have created maps to this pattern. let me explain. i take
> the Model to be the back-end application. In my example case that would
> the Fruity Fun App. It is the application, indifferent to any user
> interface. then the Viewer is the GUI engine? --that which renders the
> GUI? In my example that dosen't really yet exist, and at best could be
> said to be STDOUT. am i right about this? but then the Controller, it
> would seem, is the same entity as the GUI engine which also handles the
> user interaction. i'm a bit confused on that point. what i am calling a
> model in my GUtopia API is the code to generate the UI, perhaps then it
> is really a View? but my model/View is also fully absatracted and knows
> nothing about the Model/application for which it will describe the UI.
> the two only relate via an intermidiary description called the binding.
> so how does that fit into the MVC picture? i hanker this guess: the
> underlying engine is irrelevent, the Model is my application, the View
> is what i am calling a model (its a model of the UI) and the bindings
> are the Controller. would that be correct?

Try thinking of it this way:

The Model is as you understand it, It's an object hierarchy that just sits
there and responds to messages. It only gets messages from the controller.
The View also talks only to the controller but it's a two way street. The
view sends messages when the user types or clicks a widget and it updates
it's display when the controller sends it new data. The controller is there
specifically to isolate the Model from the View(s). The notion is that the
Model is portable and the View is easy because you can make it with some
kind of "draw a GUI" program. All the hard interface logic is in the
controllers.

I keep talking about 'the view' and 'the controller' but an app with
multiple windows with multiple panes might have several views and
controllers. The spatial containment hierarchy on screen is mirrored by the
message hierarchy of the controllers.
-- 
I have suffered from being misunderstood, but I would have suffered a hell
of a lot more if I had been understood. -Clarence Darrow, lawyer and author
(1857-1938)