Active data link (ADL)
ADL is just an extension for event driven applications. In contrast to traditional event driven GUI applications ADL adds data events to application control. Data events are translated and passed to appropriate GUI controls.
Data events are not only events signaling state transitions for the instance data, but include also events signaling state transition of the hosting property handle, i.e. selecting or reading new instances, unselecting an instance in a property handle etc.
In order to pass data events to controls, data sources (property handles) have to be linked to GUI resources (controls, applications). By connecting ODABA property handles, which represent the data sources for controls, to OGUI controls, process events fired by property handles can be passed to GUI elements.
This allows providing a generic application logic manager that does most of the work to be done when implementing application logic.
Process events are generated and passed to a receiver, which has to be registered for the property handle emitting the events. Process event are conceptually the same as context events but differ in the way they are submitted. While a context event is emitted in the moment of relevant state transitions in the property (e.g. new instance had been read), the process event is cached, until the wrapping top read transaction terminates.
Since process events are submitted at end of read transaction, process events emitted are post events, always. Pre-events can be handled in context class event handlers, only, and are not supported on application level.
In contrast to context events, which are passed to the context class instance of the property handle, process events ape sent to all receivers, that had been registered for the property handle.
In OGUI, each property handle acting as data source for a control is registered as process event receiver for this property handle. In case that two controls refer to the same data source, both controls will receive events from the property handle.
Read transactions are wrapped around most property handle functions in order to collect, cache and optimize process events. Thus, all process events generated by subordinated property handles are cached as well as process events generated from business rules executed while running the function. When the read transaction terminates, process events will be released bottom-up (i.e. beginning with events for subordinated property handles) and by event priority.
Read transactions can be nested, i.e. the application may also start an explicit read transaction in order to cache events e.g. while filing a list or tree control.
Read transactions are not wrapping application transaction, i.e. within an application transaction any number of read transactions may start and stop.