If then else
Event action – Abstract
Purpose: Evaluates one or possibly more rules to allow case discrimination between alternative blocks of event actions within an event handler.
The event action If then else can be used to specify a case distinction or the conditional execution of actions in an event handling depending on Regeln.
As outlined in the following scheme, starting from a simple condition (IF►THEN►ACTIONS), the case distinction can be extended modularly via further rules in the ELSE part, with each new (ELSE) IF rule opening a new branch with its own actions.
Specifying a rule is technically optional in any branch. However, for a branch without a rule, the default is 'Static: True' (see Static rule), which makes further ELSE branches irrelevant. In this respect, a rule should only be omitted in the 'final' ELSE branch.
Of course, if necessary, the If then else can also be 'nested', that is, used within the actions of a branch of another If then else event action.
Configuration
|
When collapsed, an If then else event action appears by default as shown in the upper right corner. The value in the label (here: 3) indicates by default the number of configured branches of case distinction. Below, a just inserted If then else event action can be seen expanded, which also does not contain a branch at the beginning. The first branch can be created by clicking on the |
|
|
When a first branch is added to the case distinction, the following controls are available:
|
|
icon.
►NOTE◄ In practice, it may be necessary to subsequently change the order of branches in an If then else event action. This is possible with the context menu functions for 'Cut' and 'Paste'.
However, changes to the sequence can also be executed via drag & drop in the tree view of the event handler:
|
The screenshot on the right shows an If then else event action with two branches (IF Company rule ELSE-IF Role rule). The screenshot below shows a section of the tree view for this configuration:
|
|
►NOTE◄ The order of the branches can have a significant impact on the logic of case differentiation and even the performance of event handling. If the logic allows, potentially computing-intensive checks (e.g. a Check existence) should be arranged as far to the right as possible in the chain. They may be executed 'less frequently' as a result. |
|
Examples
Simple use case: Conditional execution of an action
Within an event handling, a specific view (e.g. a modal dialog) is opened exactly when the login context refers to a certain role ('Administrator').
A Role rule is used here as an IF rule, which checks whether the selected role “Administrator” is used in the applicable login context (see Role of session).
In the corresponding THEN branch, the action Open view (Action) is attached below it.
More complex use case: Multi-branch case distinction
The previous example is expanded so that a specific view appears for the roles 'Basic user' and 'Anonymous user' and only a simple popup note appears for other roles.
The already existing branch (rule and action) can be copied via the menu icon and inserted as a new ELSE branch.
Then, the settings for the Role rule and the THEN action for the copied branch can be adjusted as shown in the image.
Another ELSE branch is added which does not contain an IF rule, only the THEN action Show alert (Popup).
►NOTE◄ In the example, the logged-in user can only use one specific role at a time, so the order of the branches with the rules does not matter. If, on the other hand, different independent criteria are checked, the order of branches plays an important role, because the case distinction is only processed from left to right as long as none of the rules are passed.