johnson@p.cs.uiuc.edu (11/09/88)
>I am interested in your wise judgement(?) on the Model-View-Controller User >Interface (oops!) Paradigm in Smalltalk-80. There is a big difference of >opinion on this lately. What the question is : > >Is MVC a good idea? If yes, then is its Smalltalk implementation good? Good compared to what? MVC was a major step forward in the early 80's. Lots of systems have taken ideas from it and built upon them. There are pieces of MVC that desparately need to be rewritten, like ParagraphEditor, and some features that, in retrospect, were mistakes, like the polling behavior of controllers. However, if you are programming in Smalltalk then you should use MVC until you know enough to think you can do better. If you mean should the user interface be separate from the application and should an object-oriented system be used to build the user interface then the answer is "yes". If you mean should any view be capable of having subviews and should controllers poll then the answer is "no". If you mean should views and controllers be separate objects or should one object implement both a presentation and user interaction then the answer is "maybe". Ralph Johnson
johnson@p.cs.uiuc.edu (11/14/88)
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