Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!pasteur!ames!ncar!tank!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.lang.smalltalk
Subject: Re: Is the Model-View-Controller concep
Message-ID: <80500045@p.cs.uiuc.edu>
Date: 14 Nov 88 15:30:00 GMT
References: <3098@uoregon.uoregon.edu>
Lines: 23
Nf-ID: #R:uoregon.uoregon.edu:3098:p.cs.uiuc.edu:80500045:000:1388
Nf-From: p.cs.uiuc.edu!johnson    Nov 14 09:30:00 1988


A Controller maps user input events (i.e. key presses and mouse movements)
into messages to the model and to the view.  Most Controller classes
inherit most of their functionality and only define a new menu.  Pluggable
views are a way to eliminate these classes, because a pluggable controller
gets its menu from the view, which gets it from the model.  When you create
a pluggable view, you give it a symbol which it sends to the model to get
the menu.  Thus, several pluggable views can have the same model and they
can all get different menus from the model, since they will be parameterized
with different symbols.  Pluggable views are also parameterized by messages
to signal significant events, where the definition of significant events
depends on the kind of view.  For example, a significant event for a list
is selecting an element, getting all the elements of the list, etc.

Pluggable views are OK for textual interfaces like the Browser, but they
don't cover graphical interfaces like a VLSI editor or a PERT-chart
editor.  For this you will have to write a new controller to handle
selection, dragging, etc. of graphical components.  Pluggable views are
a great time saver, but every time I use them I think that there must be
a better way.  I end up putting too much of the user interface definition
in the model, and this goes against the philosphy of MVC.

Ralph Johnson