Conditional value
See also: If then else (Event action)
Value resolver – Abstract
Purpose: Determines the return value based on a case distinction that can be constructed in the same way as the If then else event action with an arbitrary number of branches.
The Conditional value resolver determines the return value based on a case distinction, which can be constructed in the same way as the If then else event action with any number of branches.
Unlike an If then else event action, which is available only in the context of Event handling, the Conditional value resolver can be used in all contexts that use value configurations. Among other things, the Conditional value allows case differentiation within a concatenation of value resolvers, which can enable more compact and transparent configurations in all contexts (Event handling, Association criteria, Search API, etc.).
Example:
Each branch of the case distinction links a rule configuration (see diamond symbols above) with a value configuration (see trapezoid symbols below). Both configurations are optional:
If the rule configuration is omitted, then the branch condition is considered to pass by default.
If the value configuration is omitted, then the following applies to the 'No value' branch ($null)
The input value for the value resolver is passed step by step from left to right to the branches of the case discriminator until either the condition configured for a branch applies or a branch is reached for which no rule configuration exists (see the 
icon on the right in the image).
The value configuration for the branch in question determines the return value of the value resolver.
In the above example, the input value type is checked in two stages:
If the Typprüfung for 'String' is passed, a Trim value resolver removes marginal spaces from the input value (if any) to determine the return value.
If a Typprüfung for 'Long' OR 'Number' is successful, the Format number value resolver creates a 'String' for the return value from the numeric value in the input value.
If none of the checked types matches, the static text VOID is set as the return value.
Configuration
|
Immediately after adding the value resolver, it appears 'without branches' as shown at the beginning. Clicking on the
The input value (symbolized by the arrow from above) is available for both rule configuration and value configuration. ►NOTE◄ If no value configuration is used at all, a branch may return 'No value' ($null) instead of the input value. The input value must be actively 'passed through' if required, for example by an Object property value resolver without selecting a field or an Input object (type safe) value resolver with a suitable type. |
|
|
In the top left corner of a branch, the context menu icon provides access to useful operations for editing the configuration:
►NOTE◄ The sequence of already created branches can be changed e.g. by a combination of Cut and Paste operations. However, it may be more efficient to resort to the surrounding configuration's tree view, where the order branches can be adjusted via drag & drop. |
|
Example
Simple use case: Conditional field selection for a comparison
An association criteria (see Association criteria) should always be considered 'passed' if a user (see Users) or guest user (see Guest users) is logged in whose logon basis is 'threatened':
As a potential threat to the user, the 'password expiry date' should be monitored.
For the guest user, the limited validity of the account ('Valid until' field) should be monitored as a 'threat'.
The association criteria should be effective in both cases if the corresponding cut-off date is before the end of the current month.
Configuration:
The mapped association criteria within a With rule refers to the User of session as the reference object for an Entity property rule.
Within the Entity property rule, the relevant date field for the respective account type is per Compare with (Form designer) the end of the current month, which is determined using a Relative date with time value resolver.
The date field that is decisive for the logged-in account type is assigned here via the Conditional value value resolver:
The first branch determines whether a user is logged in by Typprüfung. If this is the case, the 'Password expiry date' (passwordExpiryDate) field should be checked by comparison.
The second branch uses a Typprüfung to determine whether a guest user is logged in. If this is the case, the 'Valid until' (validTo) field is checked by comparison.
►NOTE◄ Since in the specific case neither the user account has a validTo field nor the guest user account has a passwordExpiryDate, one could also 'determine' the relevant field in each case with the default value value resolver. However, the Conditional value covers the general case of an optional access much more flexibly and transparently than the Default value, which can assign an alternative value only as a fallback.