From: Massimiliano Mirra <list@...>
Date: 2002-07-25T17:05:41+09:00
Subject: Re: GUI's and the Rouge, Part III (yes, finally) 1/2

On Thu, Jul 25, 2002 at 05:26:38AM +0900, Tom Sawyer wrote:
> 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.

Well, not exactly.  Consider:

class SpreadSheet
  def [](row, column)
    ...
  end

  def []=(row, column, value)
    ...
  end

  def calc
    ...
  end
end


This is a model, yet not an application.  An application presupposes
user interaction, while you can only interact with your SpreadSheet
model from code.

> In my example case that would the Fruity Fun App. It is the
> application, indifferent to any user interface. 

I've lost track of examples, but yes, replace the above word
`application' with `model' and you have it.

> then the Viewer is the GUI engine? --that which renders the GUI?

If you say Viewer, I'd guess so.  I've always read MVC as Model, View
(not Viewer), Controller.  So the View is whatever shows the model
status to the user.  It is not implicit in the name, but it is usually
accepted that it also sends user input to the model or to the
Controller (in simpler designs the Controller is sometimes integrated
in the View).

> In my example that dosen't really yet exist, and at best could be
> said to be STDOUT. am i right about this?

As I said I've lost track of examples, but if you have something sent
to STDOUT you've already got some kind of presentation beside the
model, whether this fits in a MVC pattern or not.

> 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?

Except for the model/application bit (the application is the whole),
I'd say yes.

Also see if this point of view (no pun) can be useful to you: the View
thinks in terms of appearance: `button', `menu' and `checkbox'; the
Model thinks in terms of meaning: `surname', `telephone', `address';
the Controller translates action on appearance (`click button') into
action on meaning (`edit surname'), and, conversely, change of state
in meaning (`surname changed') into change of state in appearance
(`edit field updated').

By the way, I'm an artisan, not a computer scientist.  Take what I
tell you with a grain of salt, and the way I tell it with, well, a
whole bag of it. :-)


Massimiliano

p.s.: Did you receive my mail with the URL for the instant messenger
built around GUI abstraction?