Using event-state in your module

When modules are developed independently from each other, the event-state module can facilitate communication between them without a direct synchronous commands. The module follows a familiar listener/notification pattern in which classes can register listeners that can handle GUI events that other classes 'fire'. The interfaces and base classes in the event-state module can be extended if additional event information needs to be shared among specific modules.

Example

To illustrate the event-state, we'll use the WORKFLOW_EXECUTION_COMPLETE StateChangeEvent. This event type can be broadcast when all tasks associated with workflow execution are complete. Classes that implement the StateChangeListener interface are added as listeners via the StateChangeMonitor singleton:

StateChangeListener myListener = new StateChangeListener() {
	public void handleStateChange(StateChangeEvent event) {
		// do something
	}
};
StateChangeMonitor.getInstance().addStateChangeListener(StateChangeEvent.WORKFLOW_EXECUTION_COMPLETE, myListener);

Here, 'myListener' listens for and handles the WORKFLOW_EXECUTION_COMPLETE event that is fired elsewhere in the codebase:

StateChangeEvent event = new StateChangeEvent(source, StateChangeEvent.WORKFLOW_EXECUTION_COMPLETE, reference);
StateChangeMonitor.getInstance().notifyStateChange(event);

Gotchyas

Events are fired to all listeners regardless of what frame they might be associated with. This means that it is usually necessary to check the the source and/or reference object that are included in the StateChangeEvent object to make sure the listener should indeed handle the event that was received. In some cases all frames should handle the event no matter what the source, but usually events are meant to be kept within the same model reference and gui frame.