Event Behavior

Event behavior refers to how the listeners are called in relation to each other, whether the result for the listeners is available, and what form the result would take.

Event behavior is meaningful for base applications, as well as extensions, and is not specific to events defined in the "interface".

Event Behavior Types

The event behavior does not define the order in which the listener chains are called; event behaviors define whether they are called serially or in parallel, whether the Action that raised the event waits for listener resolution, and what the "result" of the listener invocation looks like.

For event behavior, "serially" means:

• All event listener chains for a single event listener (in a container) are called sequentially, in declared order. This means that a listener action chain is not called until any previous actions in the chain have finished.
• The event listeners for the next container's listeners are not called until the listener action chains for any previous container's event listeners have finished.

The following table describes the event behavior types.

Event Behavior	Description
Notify	Parallel - The event is triggered but the application does not wait for the extension to process it. Chain results are not available to the Action (or helper) that fired the event (because the listeners are called without waiting). This is the default behavior.
NotifyAndWait	Serial - Each action chain listener must complete (and resolve any returned Promise, if any) before another event listener action chain is called. Chain results are not available to the Action (or helper) that fired the event.
CheckForCancel	Serial - Each action chain listener must complete (and resolve any returned Promise, if any) before another event listener action chain is called. If any of the listener Chains returns a "success" with a payload of { "stopPropagation": true }, the application will stop calling event listeners. When calling listeners defined in both extensions and the base application, the listeners in the "closest" extension are called first. In other words, extensions of extensions are called before extensions of the base. This allows higher-priority extensions to cancel listening before the lower-priority extensions (or base) receive the event. Chain results are not available to the Action (or helper) that fired the event.
Transform	Deprecated. Replaced by TransformPayload.
TransformPayload	Serial - Each action chain listener must complete (and resolve any returned Promise, if any) before another event listener action chain is called. The "eventListener" will have access to a new context variable, $previous, which is a peer of \$event. This will be the result of the previous listener invocation's chain result, or undefined for the first invocation. The "eventListener" for a "transform" event can also have a "returnType" declaration, analogous to the "payloadType", but corresponding to the \$previous value. If the event declaration has a "returnType", $previous should match the type, otherwise, it will be coerced to the type. When calling listeners defined in both extensions and the base application, the listeners in the "base" are called first. In other words, the base fires an event with a value, and the extensions may optionally modify that value. (This convention is the opposite order of the "cancel" behavior). The final result, "returnType", when all the listeners have been called, will be returned as the result of the fireCustomEventAction that initially raised the event. If the application wishes to use the "transform" mode, the convention it should follow is: For any listeners for an event with a "transform" behavior that references more than one Chain, the Chains are called in array order. All listeners for an event with a "transform" behavior should pass the $previous as an argument to their Chain ( and this will typically be wired by the design time). All listeners for an event with a "transform" behavior should define a "returnType", which matches the "returnType" for the event declaration. The Chain variable argument that corresponds to $previous should have an argument that matches the "returnType" of the event, and the Chain should also have a "returnType" that matches the listener's "returnType" (note that " payloadType" and "returnType" cannot currently reference defined Types). The Chain should have a "returnType" defined, that matches the "returnType" of the event. The design time can add parameters for the listener, and the inputs for the Chain, to provide \$previous, in the same way it currently provides the $event.