The Delegation Event Model
The modern approach to handling events is based on the delegation event model, which defines
standard and consistent mechanisms to generate and process events. Its concept is quite simple:
a source generates an event and sends it to one or more listeners. In this scheme, the listener
simply waits until it receives an event. Once an event is received, the listener processes the event
and then returns. The advantage of this design is that the application logic that processes events
is cleanly separated from the user interface logic that generates those events. A user interface
element is able to "delegate" the processing of an event to a separate piece of code.
In the delegation event model, listeners must register with a source in order to receive an
event notification. This provides an important benefit: notifications are sent only to listeners
that want to receive them. This is a more efficient way to handle events than the design used
by the old 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 it wasted valuable time. The delegation event model eliminates this overhead.
NOTE Java also allows you to process events without using the delegation event model. This can
be done by extending an AWT component. This technique is discussed at the end of Chapter 24.
However, the delegation event model is the preferred design for the reasons just cited.
The following sections define events and describe the roles of sources and listeners.
In the delegation model, an event is an object that describes a state change in a source. It can
be generated as a consequence of a person interacting with the elements in a graphical user
interface. Some of the activities that cause events to be generated are pressing a button, entering
a character via the keyboard, selecting an item in a list, and clicking the mouse. Many other
user operations could also be cited as examples.
Events may also occur that are not directly caused by interactions with a user interface.
For example, an event may be generated when a timer expires, a counter exceeds a value,
a software or hardware failure occurs, or an operation is completed. You are free to define
events that are appropriate for your application.
A source is an object that generates an event. This occurs when the internal state of that object
changes in some way. Sources may generate more than one type of event.
A source must register listeners in order for the listeners to receive notifications about
a specific type of event. Each type of event has its own registration method. Here is the
public void addTypeListener(TypeListener el)
Here, Type is the name of the event, and el is a reference to the event listener. For example,
the method that registers a keyboard event listener is called addKeyListener( ). The method
that registers a mouse motion listener is called addMouseMotionListener( ). When an event
occurs, all registered listeners are notified and receive a copy of the event object. This is known
as multicasting the event. In all cases, notifications are sent only to listeners that register to
Search WWH :