Java AWT: Delegation Event Model

In the event-delegation model, specific objects are designated as event handlers for GUI components. These objects implement event-listener interfaces. The model for event processing in version 1.0 of the AWT is based on inheritance. In order for a program to catch and process GUI events, it must subclass GUI components and override either action() or handleEvent() methods. Returning "true" from one of these methods consumes the event so it is not processed further; otherwise the event is propagated sequentially up the GUI hierarchy until either it is consumed or the root of the hierarchy is reached. The result of this model is that programs have essentially two choices for structuring their event-handling code:

1. Each individual component can be subclassed to specifically handle its target events. The result of this is a plethora of classes.
2. All events for an entire hierarchy (or subset thereof) can be handled by a particular container; the result is that the container's overridden action() or handleEvent() method must contain a complex conditional statement in order to process the events.

Delegation Event Model

In the delegation event model,listener must register with a source in order to receiver an event notification .this provides an important benefits :notifications are sent  only to listeners that want to recieve the.This is a more efficient way to handle events than the design used by the java 1.0 approach ,Previously an event was propagated up the containment hierarchy until it was handled by a component .This required components to receive events that they did not process and is wasted valuable time .The delegation event model eliminates this overhead

The primary design goals of the new model in the AWT are the following:

• Simple and easy to learn
• Support a clean separation between application and GUI code
• Facilitate the creation of robust event handling code which is less error-prone (strong compile-time checking)
• Flexible enough to enable varied application models for event flow and propagation
• For visual tool builders, enable run-time discovery of both events that a component generates as well as the events it may observe
• Support backward binary compatibility with the old model

Note: These goals are described from the particular perspective of the AWT. Since this model has also been designed to accommodate the JavaBeans architecture, the design goals from the JavaBeans perspective are described in the "Events" section of the JavaBeans Specification and may vary slightly from these goals.

Delegation Model Overview

Event types are encapsulated in a class hierarchy rooted at java.util.EventObject. An event is propagated from a "Source" object to a "Listener" object by invoking a method on the listener and passing in the instance of the event subclass which defines the event type generated. A Listener is an object that implements a specific EventListener interface extended from the generic java.util.EventListener. An EventListener interface defines one or more methods which are to be invoked by the event source in response to each specific event type handled by the interface.
An Event Source is an object which originates or "fires" events. The source defines the set of events it emits by providing a set of set<EventType>Listener (for single-cast) and/or add<EventType>Listener (for mult-cast) methods which are used to register specific listeners for those events.
In an AWT program, the event source is typically a GUI component and the listener is commonly an "adapter" object which implements the appropriate listener (or set of listeners) in order for an application to control the flow/handling of events. The listener object could also be another AWT component which implements one or more listener interfaces for the purpose of hooking GUI objects up to each other.

Event Hierarchy

Events are no longer represented by a single Event class (like java.awt.Event) with numeric ids, but instead by a hierarchy of event classes. Each event class is defined by the data representing that event type or related group of events types. Since a single event class may be used to represent more than one event type (i.e. MouseEvent represents mouse up, mouse down, mouse drag, mouse move, etc), some event classes may also contain an "id" (unique within that class) which maps to its specific event types.
The event classes contain no public fields; the data in the event is completely encapsulated by proper get<Attr>()/set<Attr>() methods (where set<Attr>() only exists for attributes on an event that could be modified by a listener).

Event Delegation Model is based on four concepts:

The Event Classes
The Event Listeners
Explicit Event Enabling
Adapters