1 The application or operation requests to register a handler for a specific local or remote event. If the application is doing the requesting, this typically occurs during the startup process of the application.
2 If the event manager finds the notifier for the event in the given context or in the event manager's table of notifiers, the event manager adds the handler to the notifier's list of registered handlers.
If the event manager cannot find the notifier in the context or in its table of notifiers, it assumes that the notifier is defined on the server and therefore the event is a remote event. The event manager adds the handler to its table of handlers. (The entry for the handler includes information about the event name, the notifier name, and, if provided, the workstation that signals the event.) If you do not provide the workstation parameter, the system sets its value to "default". This value means that the handler listens for the event signaled by a notifier from any server workstation with which the client workstation has a session.
3 When a notifier generates an event, it goes through its list of handlers and calls the dispatchEvent method of the first handler in the list of handlers for the event.The notifier calls the handlers in the reverse order of their registration. That is, the last handler registered is the first handler called.
Note If the application registers interest in a remote event, the remote event manager is a handler in the event notifier's list of handlers. If you do not add another handler for the event, the notifier calls the dispatchEvent method. This action starts the default process, which is to send the event to the interested remote workstation using the Client/Server Mechanism as described in How the event manager handles remote events.
If the application registers a handler for a remote event without using the event manager's registerInterestForRemoteEventmethod, the server operation (and not the server event manager) must send the event to the listening client workstation. To do so, on the server workstation, the handler's dispatch method must get the C/S Server instance and the destination workstation TID from the operation context. The dispatch method must then call the sendEventmethod and pass this information as arguments. To remotely propagate the event, the Client/Server Mechanism sends the event to the listening workstation. The Client/Server Mechanism notifies the client's event manager of the arrival of the remote event using a standard Java CSNotificationEvent. The client event manager then gets the remote event and notifies the registered handlers. Because different remote workstations can signal the same event from the same notifier, the event manager identifies the workstation that sent the event using an attribute of the DSEEventObject.
4 When a handler receives an event, it determines whether it will consume the event or propagate it to the next handler waiting for it. If the dispatchEvent method returns "this", the notifier propagates the event to the next handler on the list. If the dispatchEvent method returns null, the handler stops propagating the event. This means that the notifier might not send the event to all the registered handlers.
Note If the notifier propagates the event to a remote handler, the notifier does not expect a reply because remote notification is asynchronous.
The following diagram shows an event being processed by a chain of handlers. The DSENotifier object has three handlers (aHandler1, aHandler2, and aHandler3) that are listeners for the event called noDocument. When the DSENotifier instance generates the event noDocument (signalEvent ("noDocument")), it is sent to the handler instance called "aHandler1". The handler instance called "aHandler1" is not interested in the event, so it returns the value "this" to pass the event to the next handler in the chain. The second handler processes the event and decides not to propagate it by returning null. The third handler is never called, even though it is capable of processing the event.
