4
Event management

This section illustrates various techniques to manage events.Central examples are a calculator application and applet that can be operated with the mouse and the keyboard and a multi-document editor based on an application framework.

The techniques are designed to reuse graphical and algorithmic elements in a system as arbitrarily as possible. This is backed by some classic concepts:

	Model	a reusable algorithm; e.g., the chip of the calculator.
	View	reusable user interfaces; e.g., buttons and display of the calculator.
	Controller	the necessary glue to connect it all.

Models and views are completely independent of one another and individually reusable; only controllers are problem specific. The AWT classes are mostly views, the Listener classes presumably are building blocks for controllers.

[ Applet] These links permit viewing the examples as applets in a Java enabled browser. It turns out that only hotjava and appletviewer support the new event handling correctly; netscape 4.04 cannot handle the examples, even after the patch awt.jar is applied. Sun's Java Activator 1.1 (early access 2) cannot show these applets either.

Topics

	4-1	A calculator as a finite state automaton	169
	4-2	A configurable keyboard	173
	4-3	A calculator application	179
	4-4	A calculator with javacc	181
	4-5	From ActionEvent to InputStream	186
	4-6	A calculator application with threads	192
	4-7	Observable	194
	4-8	A calculator application with a log	197
	4-9	A framework for multi-document applications	201

When sending a message, i.e., calling a method for a particular receiver, arbitrary method signatures can be used and arbitrary information can be passed and returned. If necessary, java.lang.reflect could be used to delay most decisions until runtime.

When acting as a listener, the receiving method signature and associated information is fixed and nothing can be returned. However, an arbitrary number of receivers can choose to receive the same information.

Which of the techniques to use and where to implement the listener, if any, is a significant design choice, especially, because the listener can additionally be nested, affording further flexibility.

If the listener is nested on the event sender (view) side, status information can be sent, but the augmented view is probably not very general.

If the listener is nested on the event receiver (control?) side, sender decoding is implicit and significant interaction with the receiver state is possible. Additionally, different kinds of events can be mapped to the same receiver reaction.

29/Apr/1998