In list
See also: Equals
The In list compare type checks in the context of an Entity property rule whether the 'list' (List, Set, Array) defined as a Compare value (value configuration on the right) contains at least one entry that passes an Equals comparison with the Check value (value configuration on the left).
If the Compare value (right) is not a 'List' (List, Set, Array), it is used directly.
If the data type of entries in the Compare value differs from the data type of the Check value, a type conversion to the type of the Check value is attempted in the same way as described for the Equals comparison type. This also applies to the case where the Check value is a list.
For the comparison of data objects, the logic of an Equals comparison with the Deep compare option switched off applies.
►IMPORTANT◄ The In list compare type relies on the logic of the Equals compare type. A robust understanding of the details and peculiarities of the Equals compare type is strongly recommended as a basis for the safe use of the In list compare type.
Specific example:
|
Check value |
Compare value |
Check result |
Comments |
"DEF" |
["ABC","DEF","GHI"] |
|
List in Compare value contains the Check value (direct) |
4600 |
["3591","04600","39052"] |
|
The second list entry in the Compare value is converted to the integer 4600 defined as the Check value. |
32 |
["32.1608", "32.0"] |
|
The second list entry in the Compare value is converted to the integer 32 defined as the Check value. |
32 |
[31.999, 32.1608] |
|
The second list entry in the Compare value is converted to the integer 32 defined as the Check value. |
["EDME"] |
["LOWS", "EDME", "EDMQ"] |
|
The third list entry in the Compare value is converted to the list defined as the Check value (with one entry). |
["EDME"] |
"EDME" |
|
The Compare value (String) is converted to the Check value defined list (with one entry). |
["EDML", "EDMV", "EDMY"] |
["EDMV", "EDMY"] |
|
None of the list entries in the Compare value matches the list provided as the Check value. |
["LEPA", "EDDM"] |
[["EDDM", "LOWI"], ["LEPA", "EDDM"]] |
|
The second list entry in the Compare value matches the list defined as the Check value with two entries. |
"[LEPA, EDDM]" |
[["EDDM", "LOWI"], ["LEPA", "EDDM"]] |
|
The second list entry in the Compare value returns the string defined as the Check value as a String image. |
"[EDDM,LOWI]" |
[["EDDM", "LOWI"], ["LEPA", "EDDM"]] |
|
None of the list entries in the Compare value returns exactly the String defined as the Check value as a string image. |
|
Comparison of 'client objects': |
|||
{"name":"robinson"} |
[{"name":"friday"}, {"name":"robinson"}] |
in server context:
in Client workflow:
|
In a server-side execution context (within Event handling, Association criteria, etc.) data objects are basically compared by content, i.e. by their specific property values. In a Client workflow, a 'Client object' is only recognized as 'equal' if it is the same 'Client object'. A comparison of the contents does not take place. |
|
We create the two 'Client objects' from the list in the compare value (above) in advance and assign them to two variables (named robinson and friday). |
|||
|
|
|
|
Since in this example the list entries refer by reference to the 'Client objects' created in advance, the In list comparison is also considered to have passed in the Client workflow. For the Client workflow, the comparison appears like this:
|
|
|
|
in server context:
in Client workflow:
|
The server compares content and recognizes the match. For the Client workflow, the comparison appears like this:
Whether or not the content of Object-A is the same as Object-C is simply not examined. |
|
|
|
|
In this variant, the 'Client object' in the Check value is converted to a String by an Object to JSON. It is wrong to expect that the 'Client objects' listed in the Compare value will be automatically converted to JSON Strings for the In list comparison. In fact, a String image of each 'Client object' from the Compare value is used for comparison, but it does not reflect the JSON format. The following variant, on the other hand, leads to the goal. |
|
|
|
|
With this variant, the content comparison of 'Client objects' can be enforced independently of the execution context (client/server) by comparing their JSON format image as a string instead of the objects involved. The list of 'client objects' in the Compare value is converted by the concatenated Collect values resolver into a list of String values that map the listed objects into JSON notation. The Value to collect is defined via the Object to JSON value resolver, ensuring that the notation in detail matches the JSON string generated as the Check value if a content-matching 'Client object' is listed in the Compare value. |
true
true
false/true
►NOTE◄ A check for the presence in a list of a 'Client object' whose content matches the Check value can alternatively be achieved with a rule configuration like the following one:
|
The In list comparison type is purposefully not used here so that the check of the list provides the same results regardless of the execution context (server/client):
This may sound complicated, but it is really quite simple: The rule is passed if the list from the input value contains a 'Client object' as an entry that matches the content of the object searched for. This is because it is then considered to be the Check value for the outer Entity property rule, which satisfies the not (Is empty) condition. |
|
Configuration
The value configurations for the Check value and the Compare value are not optional for the In list comparison type.
|
As soon as the In list compare type is selected for an instance of the Entity property rule, the default value configuration for the Compare value (a Create list value resolver without entries) shown on the right appears – if applicable, instead of an existing value configuration for the Compare value (right). |
|
|
In the automatically added Create list resolver, value configurations for list entries can be assigned by clicking on the Clicking on the |
|
|
However, instead of the default value configuration, any other value configuration can be used that provides one or more suitable Compare values at runtime. |
|
symbol.
symbol removes an existing entry for a value configuration.
Examples
Simple example: Static positive list for values of a dynamic enumeration
An association criteria (see Association criteria) is considered passed in the context of a user (see Users) if the selection for the 'Locale' (locale) property is contained in a statically stored positive list.
Configuration:
|
The association criteria uses the AND conjunction of two rules as shown on the right:
|
|
More complex example: Could I login as the owner of a given entity?
An association criteria (see Association criteria) is considered to have passed in the context of an entity of any type exactly when the owner of that entity is a company (see Company accounts) that is available to the User of session when logging on to a session.
The condition is fulfilled if the Long value specified in the 'Owner' (ownerId) property of the entity can be found as an entry in the 'Companies' (companies) list property of the relevant user account (see Users).
Configuration:
|
The association criteria uses the AND conjunction of two rules as shown on the right:
|
|
If the association criteria is also used for Guest users, it is necessary to take into account that no list of companies can be associated with a guest user. Instead of the 'Company' list property, the guest user account uses a 'Company' (companyId) property for which exactly one Long value can be selected.
This configuration variant for the Compare value utilizes the option of using either a list or a single value as the Compare value for an In list comparison:
|
If the User of session is a guest user, the first three value resolvers in the chain, which are identical to the above configuration, will return 'No value' ($null). On this basis, the specific treatment for Guest users can be controlled by the Default value resolver attached to the chain. As the image on the right shows, the value resolver chain in its Default value parameter is structured in the same way as before:
►NOTE◄ The return value type for the chain is still the Long[] data type, whereas the Default value within the Default value resolver refers to the data type long. However, this does not affect the behaviour at runtime: The In list matcher will always compare a single compare value directly with the check value. |
|
|
Accessing the 'Company' property via the Object property value resolver can alternatively be done in the context of a Collect values resolver. Since the guest user account passed as input value is not a list, again only a single value ('Company') is read. However, this is returned as the only entry in a list, so during configuration the Long[] type of return value appears consistently. This additional processing step in the value resolver chain creates transparency in the configuration, even if nothing changes in the effective logic at runtime. ►NOTE◄ Indirect case discrimination via Default value resolvers within a common value resolver chain solves the problem and results in a relatively compact configuration. For the benefit of more transparency and 'readability' in the configuration, an explicit case distinction could be configured within a With rule instead, which recognizes the User of session as either a 'User' or 'Guest user' based on a Check type and then makes a specific comparison with the entity's 'Owner' ID. Then the In list comparison type must be used only for Users, while for Guest users an Equals comparison is sufficient. |
|
