Sort list

The optional Compare value parameter can be used to define a value resolver that is applied to each entry in the input value to determine a compare value for sorting.

• Without a value resolver (default), the complete list entry is used as the compare value.

The Ascending option is checked by default, which causes sorting in ascending order according to the Compare value.

If sorting in descending order is desired, the Ascending option must be unchecked.

Initially, the configuration of the Sort list value resolver provides for a single sort criterion.

• By clicking on the (plus) icon, further sorting criteria can be added to create a hierarchy with descending priority.

• By clicking on the icon ('rubbish bin'), existing sorting criteria can be removed from a hierarchy as long as at least one sorting criterion remains.

The screenshot on the right shows a configuration with two search criteria:

• The list is first sorted in descending order according to the value in the created field of the list entries.

• For entries that match in this field, the lower-ranking, second search criterion applies, which refers to the name field of the list entries and sorts in Ascending order.

►NOTE◄ If the configuration is carried out in a context that contains a tree view, these sorting criteria can be rearranged using drag & drop to adjust their priority in the hierarchy.

• The screenshot on the right shows a section of the tree view in which the sortItems element, which represents the list of sorting criteria, is highlighted.

• The two child elements labelled SortedListItem represent the sorting criteria, as can be seen from their expanded structure. The order of these elements in the sortItems node can be changed using drag & drop.

In the context of an Execute with event action, the list defined statically for demonstration purposes is first defined as the reference object for the following event actions, as shown on the right:

• From the static text (see Static values) in JSON notation, a list object is created via the JSON to object value resolver.In the action block the Show alert (Popup) event action is executed, which defines the sorted list as the text of the Message:

  • The Sort list value resolver does not define a Compare value, so the list entries are sorted directly.

  • The Ascending option has been unchecked so that the entries are sorted in descending order.

In the Sort list value resolver, a Compare value is now defined via the Random long value resolver. This value resolver randomly allocates a value from the value range for the Long data type, resulting in random sorting.

►NOTE◄ The Ascending option can be checked or unchecked. Since the sorting is random, this affects the order of the entries in the specific case. For once, however, this has no influence on the random sorting as a whole. Effectively, the order in the return value always appears randomly.

Within an event handling the (stakeholders) variable refers to a list of Companies/Clients that are involved in a business object. When saving changes, the user will be informed about the companies involved.

A separate notification appears for each company involved, reflecting selected address characteristics of the company according to a uniform scheme.

Specifically, the companies are then listed in alphabetical order by the 'Name' (address.name1) property through a series of notifications of the 'Info' type.

Runtime example:

The stakeholders variable is accessed here in the context of an Execute with event action. The image to the right shows only the event actions in the action block and (at the very top) the data type of the return value of the variable: Firmenkonto[]. For event actions, a list of the companies involved is therefore available as a reference object.

• The For each loop event action iterates across the companies involved in the input value in alphabetical order. The Resolver for entities Sort list value resolver is therefore used as the value resolver for entries:

  • In the Compare value, the 'Name' property in the company address (address.name1) is first accessed via Object property value resolver, according to which sorting is performed.

  • The concatenated Upper case value resolver ensures that the 'alphabetical order' is maintained without consideration of upper/lower case letters. Otherwise, company names in lowercase (see 'fast-or-furious Ltd.' in our example) would be displayed after all in uppercase letters.

    ►NOTE◄ Alternatively, a Lower case value resolver could be used here. It is exclusively a matter of equal treatment of A-Z compared to a-z.

• Within the loop, a Show alert (Popup) event action is executed for each company account, in which selected company account data is prepared:

  • The same property that has already been sorted is used as the Title. The upper/lower case letters are retained here as maintained in the address.

  • For the Message itself, two address characteristics (city and countryCode) from the company account are combined here in context via a Template value resolver with literal characters ('/').

    ►NOTE◄ The same result could also be achieved by a simple Concat strings. However, as the number of properties displayed increases, preparing the data using a Template value resolver may be clearer and easier to maintain.

To achieve multi-level sorting, only one additional sort criterion (per ) needs to be added for the 'Country' (countryCode) field within the existing configuration.

►NOTE◄ As the screenshot on the right shows, this should be positioned at the top of the list. However, adding always creates a follow-up criterion, so that a new 'top criterion' can only be placed by subsequently moving it in the tree view (see 'Configuration') or through more complex interactions.

►IMPORTANT◄ The Object property value resolver for the 'Country' (countryCode) returns a value from the dynamic enumeration for the Country, type, which is used here directly as a sort criterion.

Based on the sorting for the top criterion 'Country' in the specific example (DE < IE < IT), it could be assumed that the 'Name' (name) of the enumeration value is the deciding factor for the sorting. However, this assumption is not actually correct!

The sort order for enumeration values is regulated differently depending on the execution context (server/client):

• In the server context, the 'ordinal' (Long value) from the enumeration is sorted numerically.

• In the client context, the 'Name' (String value) from the enumeration is sorted alphanumerically.

For the countries referenced in the example – ‘Germany’ (DE/82), ‘Ireland’ (IE/106) and ‘Italy’ (IT/109) – the order is always the same by chance, regardless of whether you sort by ‘Name’ or ‘Ordinal’. Even the localization would result in the same sorting by chance.

This would look different for a list with the countries ‘Germany’ (DE/28), ‘Austria’ (AT/14) and Switzerland (CH/215):

• Sorted by ‘Ordinal’: ‘Austria’ (AT/14) < ‘Germany’ (DE/28) < Switzerland (CH/215)

• Sorted by ‘Name’: ‘Austria’ (AT/14) < Switzerland (CH/215) < ‘Germany’ (DE/28)

• Sorted by localization: ‘Germany’ (DE/28) < ‘Austria’ (AT/14) < Switzerland (CH/215)

For a stable sorting with values from dynamic enumerations, it is therefore essential to explicitly decide how these values should be integrated.

The screenshot on the right shows a variant of the above configuration, in which the ‘Name’ (name) field of the Country value is read from the ‘Country’ (address.countryCode) address field of the company account for the first sort criterion.

The concatenated Upper case resolver ensures that the sorting takes place without differentiating between upper and lower case in the ‘Name’ field. The fact that all names in the enumeration are capitalized is also just a 'fragile' convention.

►NOTE◄ In the configuration on the right, the data field path that leads directly to the name of the enumeration value has been selected in the Object property resolver:

• address.countryCode.name

The same effect can be achieved by linking two or three Object property resolvers.

The variant in the screenshot on the right looks very similar to the previous one, but does not directly address the 'Name' (name) field of the Country value from the ‘Country’ (address.countryCode) address field.

The concatenated Upper case resolver recognizes that the input value (Country type) is not a String and instead passes on its string image in upper case as a sort criterion.

• In the server context, the 'Name' (name) is a string image and the sorting is the same as in the previous example.

• In the client context, sorting is based on the localization for the Country (for the Current locale and in capital letters), which can lead to different results.

The somewhat more complex configuration in the screenshot on the right aims to force a sorting according to the localization for the Country referenced in the address for the Current locale in upper case (i.e. case-insensitive) both in the server context and in the client context:

• The Value from localization resolver uses the relevant localization with the following parameters:

  • Bundle: The bundle name is set here statically via the Class resolver for which the Country class is selected.

  • Resource: The resource name for the value of a dynamic enumeration is always the ‘name’ (name), which is read here using the Object property resolver.

  • The Default value for a Country that does not even have a localization in the default language 'English' (en) should also be the 'name' (name).

CAUTION  Even this substantial configuration effort compared to the initial ‘naive’ access to the countryCode field does not result with 100% certainty in identical sorting results being achieved between the server context and the client context using the Sort list.

For countries in the DACH region (as an example), the value resolver chain shown sends their default localizations for the Current locale ‘German’ (de) to the sorting. Specifically, these character strings:

• DEUTSCHLAND

• ÖSTERREICH

• SCHWEIZ

However, the server and client sort the umlaut 'Ö' differently (ASCII code/‘OE’), so that Austria is categorized after Switzerland in the server context and between Germany and Switzerland in the client context.