The mainstay of Eva's control mechanism is the Event.
Rather than having one controller handling the user input for each view, Eva has one manager for the entire system, the event manager. This event manager can be thought of as managing an interrupt table. Views register with the event manager telling it which events the view wants to handle and the manager interrupts the view when one of these events occurs.
If a view wishes to know when the left Mouse button is clicked inside its bounding box, it would register for the synthetic event leftButtonClickedln: (synthetic events are discussed below). Whenever the left button is clicked in the view a leftButtonClickedln: message will be sent to the view which will then process the event (see figure 4.1 below).
The components of a user interface are more clearly defined in the Eva paradigm than in MVC. Programmers using MVCs are continually facing the question, "should this operation be done by the controller or the view?". In Eva this problem is reduced because the responsibilities of the event manager are more clearly defined and intuitive. It is the event manager's job to maintain the view's interests in events and inform interested views when these events occur. It is the view's job is to handle the events from the event manager by modifying the model and updating itself as appropriate.
The task of maintaining and interpreting the interface context is split over several managers, the event manager, the screen manager and the mouse manager to name a few. Typically there is one manager for each input or output device although. Each of the managers is an Actor and so executes in parallel with the others. It is the job of these managers to combine user input and interface context creating a meaningful stream of events for each view.
In Eva it is easy to understand how a particular view behaves. Each event has a corresponding handler (method) in each of the views which are interested in it. These views must explicitly state which events they are interested in by registering for them. When an event occurs, control is passed to the corresponding handling methods for each of the registered views.
A view can be *registered* for an event which means that it is possible for the view to handle that event. If a view is enabled for a particular event then that view currently wants to handle occurrences of that event. Only views which are enabled for an event are informed when the event occurs.
The event manager keeps track of all views and the events for which they are registered in its registry. Events and the views enabled for them are kept in the event manager’s event table. The event table is used in the same way as an Interrupt Vector Table. When an event occurs the list of handlers (views enabled) for that event is retrieved from the event table. Each of the handlers in the list are informed of the event's occurrence.
The set of events which are valid at a given time are those which are in the manager's event table. Invalid events will be ignored. Old and new event types can be added or removed at any time with no adverse effects on the rest of the system. The underlying code for the event manager can also be changed without effecting existing views. Ideally the host system would not require the event manager to poll for primitive events (e.g., Mouse button down and up, etc.). Polling, if required, can be limited to a few device classes.
In practice the concept of a single event manager would be broken down into […] its component managers. For example, a mouse manager would be responsible for distributing the mouse related events. Because there are many input (event) sources individual views can receive input from many sources at the same time. In addition, consecutive events in a view's event stream need not be related or have been generated by the same device. Therefore, in Eva, it is possible to have concurrent active views with each one having multiple input foci.