~
Controllers contain routines for sensing and handling user inputs such as; Mouse movement, keypresses and button clicks.
who was originally responsible for the redefinition?
It's probably impossible to identify a single person who was originally responsible, but I just came across an early culprit who has heretofore escaped mention on this page: Jim Rumbaugh. In a September 1994 Journal Of Object Oriented Programming article he urges readers to "use the model-view-controller framework" and then, in the very next paragraph, he proceeds to write: "the state diagram of a controller defines the allowable sequences of interactions inherent in a use case ... Start by assuming one controller per use case...". So, clearly, by 1994 prominent methodologists were mis-using the paradigm's name by substituting the Jacobsonian connotation (i.e., use-case sequencer) for the Smalltalk connotation (input device interface). -- Randy Stafford (2002/04/04)
~
The controllers are constantly polling for input using these routines. When some event occurs, the controller must determine its context (e.g., a shifted mouse button down event may be different then an unshifted one) and do the appropriate action. This approach has two major problems, Polling and lack of modularity.
⇒ Polling
Since each type of view has its own input requirements and set of valid user interactions, each view has an associated controller which handles user input. In a typical system there are several different types of view and thus several different types of controller. These view/controller pairs normally fall into one of four broad groups; those dealing with text, lists or graphics and those dealing with aggregates of the above three.
~
See "an Actor/Pawn pair" ⇒ World Core Tutorial 1
~
Within a particular View/Controller Pair the code is modular, however the same is not true of the system as a whole. In each group, the view/controller pairs are organized hierarchically with subclasses differing only slightly from their superclasses and sharing most of their code. Because polling code tests a particular set of inputs, if a subclass recognizes one different input then it must reimplement the polling loop. This leads to a great deal of duplicate code and confuses the flow of control.
To illustrate some of these problems, consider the Smalltalk user who wishes to monitor all incoming data on a serial line and who does not want to create a separate task to manage this data. It is straightforward to create a text view which takes its input from the serial port. The problem is that its controller will only be active when the view is the active view. Using Smalltalk for anything else will prevent the controller's polling loop (the one that tests the serial port) from running. Solving this problem requires changing all of the polling loops in the system to include the serial port as one of the inputs.
~
> After inspecting the code, draw away on the `BlElement` created by dragging (clicking + moving mouse) **or using another input device**.
~
Construction of new Model/View/Controller triads is complex and cumbersome despite the existence of tools such as Glazier [Alexander, 1987]. Views frequently interact with others in subtle ways causing one controller to retain control of the processor and lockup the system.
Typical implementations of Smalltalk do not use MVC for everything. This leads to confusion about what particular objects should be doing. For example, most controllers have processes associated with them. The code which handles user input for popup menus does not. In fact, this code, which plays the role of a controller, is not implemented as a controller. This inconsistency increases complexity and reduces compatibility between systems and between components within systems.
MVC in Smalltalk uses the dependents mechanism to maintain the correspondence between model and view.
~
The dependency (addDependent:, removeDependent:, etc.) and change broadcast mechanisms (self changed and variations) made their first appearance in support of MVC (and in fact were rarely used outside of MVC). View classes were expected to register themselves as dependents of their models and respond to change messages, either by entirely redisplaying the model or perhaps by doing a more intelligent selective redisplay.
~
Objects can *depend* on one another such that when one is changed, all those who depend on it will be notified. This scheme is reasonable for simple applications but it allows only a single path between dependents (i.e., the changed: and update: messages). Unfortunately, an object’s dependents rely on the object to decide when to send the changed: message and the dependents who receive the update: message must determine whether or not they are interested in the change.
~
For example: Instance of LeConnectorPageContainerElement did not understand #onContentChanged
LeContentElement>>#onContentChanged #+begin_src onContentChanged "Subclasses can react to content (page and block) changes" self deprecated: 'Use #onContentUIModelChanged instead'. self halt #+end_src
~