Eventing in Services

Event specification is a little different from using action sequences in EiffelVision2 or in other action-based eventing systems. ESS should not use ACTION_SEQUENCE like in these other systems but a specialized type called EVENT_TYPE. There is a support framework for ESS wrapped around EVENT_TYPE and a observer design pattern to simplify use.

Event vs Action

A new eventing model was used in ESS as not to conflict of alter the existing mechanisms in EiffelBase. In addition, services act on or raises an "event". With respects to EiffelVision2 an action is event that is performed in response to some action.

Interface Designs

When designing interfaces or a service interface the event type to use is the base event type interface EVENT_TYPE_I. EVENT_TYPE is actually the default implementation class for EVENT_TYPE_I. The difference between EVENT_TYPE_I and its implementation EVENT_TYPE is EVENT_TYPE also implements EVENT_TYPE_PUBLISHER_I. With respects to correct encapsulation design, an interfaces should always use EVENT_TYPE_I because no interface should allow a client to publish an event. Events should only be raised in context.

deferred class
    INTERFACE_I
 
inherit
    USABLE_I
 
feature -- Events
 
    changed_event: !EVENT_TYPE [TUPLE [flags: INTEGER]]
            -- Events call when a change occurs
        require
            is_interface_usable: is_interface_usable
        deferred
        ensure
            result_consistent: Result ~ changed_event
            result_is_interface_usable: Result.is_interface_usable
        end
 
end

class
    INTERFACE_OBSERVER
 
feature -- Event Handler
 
    on_changed (a_flags: INTEGER)
            --
        require
            is_interface_usable: {l_usable: USABLE_I} Current implies l_usable.is_interface_usable
        do
        end
 
end

Event Connections and Observers

To Su