Logical condition
The Behaviour type 'Logical condition' checks whether a certain condition is met, which is formulated with reference to other behaviours configured for the same executing element.
The Logical expression defines an arbitrarily complex logic based on the three basic logical operations: conjunction (AND), disjunction (OR) and negation (NOT) in the following syntax.
Behaviour names are used as arguments for these functions, which return the truth value (true/false) of the Behaviour type at runtime. In contrast to a direct call of the respective behaviour, it is only determined whether their behaviour would execute the Actions on 'true' or the Actions on 'false'. In fact, no actions of the evaluated behaviour are executed. The behaviour does not have to contain any actions to return a truth value.
If the Logical expression returns true, the Actions on ‘true’ are executed.
If the Logical expression returns false, the Actions on ‘false’ are executed.
In the event of an error, two processes can be distinguished:
Either the Actions on ‘false’ are executed with an error message as data ($input) which can be displayed e.g. by the Show alert action. Afterwards, the chain of behaviour continues.
Or the chain of behaviour is broken completely, e.g. because there is a misconfiguration in one of the behaviours evaluated. This can be determined via the Log to console action. The behaviour is only superficially ineffective.
CAUTION
If the Behaviour type of a behaviour, which is checked during the evaluation of the Logical expression, also returns a value in the form of data in addition to the check result ('true'/'false'), this value overwrites any input data ($input) with immediate effect. At the same time, the evaluation of the behaviours addressed in the logical expression may be terminated, depending on the result of a single check, without all behaviours having been evaluated (see details on the AND/OR operation below). Which data a Logical condition effectively passes as $input to the actions and under which conditions must be carefully examined with regard to these dependencies. It is not generally guaranteed that input data passed from the Triggering event or from calling the behaviour by the Execute behaviour action is passed to the actions.
Syntax for logical operations
|
Operation |
Syntax |
Behaviour |
|
Evaluation of a behaviour |
Behaviour |
Returns the value true to the Logical expression, if the Actions on ‘true’ would be executed in the behaviour. ►NOTE◄ A faulty configuration in the evaluated behaviour (e.g. the absence of a required parameter) can lead to the evaluation being terminated. |
|
Negation |
!Expression |
Determines the return value of an expression and applies a logical negation. Here true becomes false and false becomes true. The expression can be a behaviour or an aggregate of behaviours through operations. The prefixed '!' symbol (exclamation mark) is to be understood as 'NOT(expression)', without the need for brackets. The expression !OR(A|B|C) therefore means 'Neither A nor B nor C is fulfilled'. This is equivalent to the expression AND(!A|!B|!C). |
|
AND concatenation |
AND( Expression1 | Expression2 | ... ) |
Within the AND-concatenation, the expressions separated by the pipe symbol '|' are evaluated from left to right.
|
|
OR concatenation |
OR( Expression1 | Expression2 | ... ) |
Within the OR concatenation, the expressions separated by the pipe symbol ‘|’ are evaluated from left to right.
|
►CAUTION◄ An incorrect expression (e.g. a typo in a behaviour name) only results in an error message for the entire behaviour if the expression in question is actually evaluated. Since the evaluation of expressions in an AND concatenation is terminated at the first false return value and in an OR concatenation at the first true return value, incorrect expressions in these functions may remain undetected for a long time before they become an acute source of error.
The expression AND(almost always false|does not exist) functions as long as there is a behaviour called ‘almost always false’ and it returns false. Whether there is a behaviour ‘does not exist’ is then almost always irrelevant.
The expression OR(almost always true|does not exist) functions as long as there is a behaviour called ‘almost always true’ and it returns true. Whether there is a behaviour ‘does not exist’ is then almost always irrelevant.
A Logical condition should therefore be subjected to intensive systematic tests, which also cover unusual combinations of input data.
►NOTE◄
The Logical expression can be brought into a clear structure by inserting line breaks and spaces. Expressions and behaviour are trimmed on both sides before interpretation.
Behaviour names should be chosen so that conflicts with the above syntax are avoided as far as possible. Spaces within the name are not a problem. The pipe symbol must not be included in a behaviour name because it is also a separator outside AND() and OR(). The use of a leading exclamation mark should be avoided. Round brackets are used in pairs ‘( ... )’ as part of the name, for example, in a behaviour name like ‘Consignee address (CNE)'.
If a Behaviour name is not unique within the same executing element, the behaviour at the top of the list is evaluated.
Example
In an input form for shipments, a specific button should appear exactly when a critical combination of certain characteristics is given for the planned time schedule.
The following rules must be observed in order for the ‘time schedule’ to be accepted as feasible:
The Pickup date fixed is a mandatory field and must contain a valid date in the future. In addition, only values that are less than or equal to the Delivery date requested are permitted (per Validators).
The Delivery date requested must also contain a date in the future.
In addition, the pick-up date and delivery date may only be identical if a Service type is selected that is considered an ‘express service’.
If even one rule is violated, the button Check dates and/or Service type! appears as a note.
Configuration:
Whether the time lapse for a shipment is considered ‘feasible’ is to be determined by a Logical condition that has been configured around the date selection in the example for a Column layout container. The behaviour must be called by the Verhalten ausführen action from all input fields involved, as often a change is made there (see triggering event Changed).
For the same container, a behaviour (without custom actions) has also been set up for each individual rule:
The Pickup date is valid behaviour checks with Validate element, whether a valid entry for Pickup date fixed exists.
The Delivery on same day behaviour checks with Calculate, whether the Pickup date fixed and Delivery date requested are identical.
The Express service behaviour checks with Filled with for the service type ‘Express-Parcel’ or ‘Euro Express-Parcel’.
The Logical expression in the Schedule feasible behaviour links these input data as follows:
AND( Pickup date is valid | OR( !Delivery on same day | Express service) )►NOTE◄ Line breaks and spaces have been inserted manually here for transparency.
Depending on the result, the action Show element or Hide element is executed for the button.
