Triggering event
Value resolver – Abstract
Purpose: Identifies the event that triggered the execution of the current event handling at runtime.
The Triggering event value resolver identifies the event that triggered the execution of the current event handling at runtime.
The return value is the triggering event (see Triggering events). The type of the return value is specified in the configuration as 'Interface > to action events', since triggering events of different types can occur at runtime. Basically, two categories of real events can be distinguished here:
Predefined events are assigned to different static enumerations depending on the category. Each static enumeration provides events of a specific type, e.g. 'Common'. (de.lobster.scm.actionevent.CommonActionEvent).
Custom action events are managed in the associated dynamic enumeration (Custom action event). The specific type of custom action event is always 'Custom action event'. (de.lobster.scm.actionevent.CustomActionEvent).
Specific value resolvers ('Any static enum' or 'Any dynamic enum', see Static values) define static values from the respective enumerations which can be compared in rules with the return value of the Triggering event value resolver.
As string mapping for an 'Event' returned by the Triggering event value resolver, the internal 'Name' (name) of the respective count value appears, e.g. 'CREATE' for the predefined event 'Create' from the category Common action event). This internal name can be sufficient information to inform about the triggering event in a Show alert (Popup) event action. However, using this name instead of the enumeration value in a rule that is supposed to uniquely identify the triggering event or match it against a list of comparison values is only partially recommended, since there is no mechanism to prevent an internal name from a static enumeration for predefined events from also being used as the name for a Custom action event. Therefore, the name does not necessarily uniquely identify the event unless there is an additional check type for the return value.
►NOTE◄ In the course of Tests for Event handling, the triggering event can be explicitly selected (via the 'Action event' parameter). If the Triggering event value resolver is used within the event handling configuration, specific Tests can be defined for each relevant triggering event this way. As a default value for tests whose definition does not specify an 'Action event', the 'virtual' event TESTING (with de.lobster.scm.utils.testing.TestingManager$TestEvent type) is automatically created.
Configuration
The value resolver does not use any parameters and ignores the input value.
Examples
Localized notification of the triggering event
An event handler that can be triggered by events from different categories generates a notification indicating the localization for the triggering event for the Current locale.
The title of the message should indicate the specific type of the event by localization for the Current locale.
Runtime example:
Predefined event from the Number range (Events) category:
-
Default event (in Tests):
Configuration:
|
In the action part of an event handling, the user is informed about the triggering event by a Show alert (Popup) event action. As can be seen on the right, the Show alert (Popup) event action is placed inside an Execute with event action that uses the Triggering event value resolver in the Object Resolver. On the one hand, this is useful because the 'Title' and the 'Message' are defined depending on the triggering event. On the other hand – and this is particularly important here – the entityClass variable for the Execute with event action block is automatically assigned the name of the specific type of triggering event needed to retrieve the localizations in the Show alert (Popup) event action (see below). |
|
|
The Show alert (Popup) event action must be configured as shown on the right to make the desired localizations (or default values, if applicable) appear in the notification:
|
|
Case differentiation depending on the triggering event
In the following example an event action E-Mail should be triggered, when certain events for a user data object (user account) occur if specific conditions are true:
A message is sent when a user account is 'Created' or 'Deleted'.
When a user is 'Updated' (precisely: changes are saved for an existing user account), a message should only be sent if the update is triggered by a session not referring to the 'Administrator' role.
The event handler responds to the Triggering events 'Update', 'Delete' and 'Create'.
The Validating rule checks for the entity type 'User' by Check type.
Within the If then else action, the Triggering event resolver is used to determine if a 'Create' or' Delete' element triggered the event handler...
... OR if the current session uses a role different from 'Administrator' (by a Role rule negated by the Not-option).
►NOTE◄ Provided that no further actions or conditions are added to the event handling, the check for the action event could also be integrated into the Validating rule in this example.