Event-listener models resort under SeparatedConcerns.
Event-listener models are abundant in the Java world. These provide listener classes---classes which a programmer can subclass (or interfaces that can be implemented) to provide custom implementations of special call-back methods. An instance of such a class (or an instance of an implementor of such an interface) can register its interest in events of a particular kind with a UI component, such as a button or selection box. If the UI component detects the occurrence of that kind of event, it will call the appropriate call-back method of the relevant listener instance, and so invoke the custom-supplied event handling code.
In web-based UIs, this means that one needs a programming-language-based model of the components on a page on the server (such as used with ComponentLibraries in the ViewTaxonomy). These should also be maintained in session scope, so that they can maintain their state between different requests from a particular browser.
Incoming requests are then handled in one of two ways:
The request is seen as the occurrence of a single event (usually a button having been clicked, or JavaScript being triggered by the browser). The event is related to the programming-language-based component to which it logically belongs, and that component is notified that the event took place. The component can then call any listeners for that event in response.
A whole batch of UI events are inferred from a single request. An example best illustrates the point. Assume a page has two components: a button and a selection box. Upon its initial rendering, the components representing this logical layout can store their initial values. If the user selects a different value in the selection box, the browser does not generate any events to the server. But when the user eventually clicks on the button also provided, it results in the whole form being submitted. Upon receiving this request, the values held by each server-side programming language component can be compared to the corresponding values in the submitted form, and multiple events can be derived from the single request. In this example, the selection box can infer that a selection changed event took place, since it can detect that the value submitted as part of the form is different from the stored value previously selected. The button can infer a button clicked event. And both events are handled separately by their respective event listeners, but in one batch as a result of the submitted form.