The interface exposes events as organizations of named values. The contract is that any event in the system must have a name-based way of accessing sub-data within its event type. A simple example is a Java bean: the names can be property names, and those properties can have still more properties beneath them. Another example is a Map structure. Here string names can refer to data objects.
The interface presents an immutable view of events. There are no methods to change property values. Events by definition are an observation of a past occurrance or state change and may not be modified.
Information on the super-types (superclass and interfaces implemented by JavaBean events) is also available, for Java POJO events as well as for Map event types that has supertypes.
Implementations provide metadata on the properties that an implemenation itself provides.
Implementations also allow property expressioms that may use nested, indexed, mapped or a combination of these as a syntax to access property types and values.
Implementations in addition may provide a means to access property values as event fragments, which are typed events themselves.
getEventType methods to ensure only once instance for each {@link #getType()} is created. The {@link #intern()} method furthers this functionality allowing clientcode to ensure they have the correct, single instance.
@author Eric Dalquist
@version $Revision$
e.g. Hearing Date, Mention Date, Bring up Date
@author mugo | |
| |
| |
| |
| |