Configuration

The following specific properties define the configuration of a Repeatable element container:

Min. entries/Max. entries define the lower and upper limits for instances of the repeated element at runtime. 0 or empty disables the respective limit.

►IMPORTANT◄ The setting for Max. entries is ignored when data is loaded and only limits the addition of new entries. It is not considered as a validation criterion and the container can be saved with 'surplus' entries. If a container contains less entries than defined by Min. entries, the form will show additional (empty) instances of the repeated element. As long as this does not produce required fields or read-only fields with default values, the lower limit is also not considered as a validation criterion and an object can be saved while lacking the required number of entries for a container.

The options Allow add by user and Allow remove by user define whether the and symbols appear at runtime. The visibility of these symbols can also be controlled by the action Allow add/remove. When the symbols are disabled, the actions Add element (optional/repeatable element) and Remove element (optional/repeatable element) can be used to add or remove elements.

►NOTE◄ If the Min. entries/Max. entries parameters are set to the same value (>0), the and symbols do not appear disabled, but disappear completely.

A link for Synchronized numeric element can be used to synchronize the count of instances in the repeatable element container with the value of a numerical (or text) field.

►IMPORTANT◄ This synchronization works bidirectionally, so numerical entries for the value in the synchronized input field control the number of instances in the container.

• Increasing the number adds new instances. Decreasing the number removes instances, deleting their content, if any.

• These manipulations can also be used for automation purposes, like deleting entries or defining a preset number of instances.

• If users should receive interactive access to the synchronized field, the number of entries should be restricted (by Min. Entries and Max. Entries), to prevent them from accidentally adding large numbers of instances in the container. Basically, direct interactive access to the synchronized field should be strictly limited if not avoided.

The Field for change notice (Portals only) parameter specifies the name of a data field, which is automatically populated by change operations (create, update, delete) for instances of the repeated element in the form. See section 'Change notice' (below) for details.

The parameters Display option and Page size only apply and appear for View type 'Grid' (see the following section).

• Display option features the choices Details top, Details bottom or Datagrid only for positioning the details section (if any) in grid view (see below).

• Page size defines the number of rows to show per page in a grid. 0 or empty deactivates paging for the grid.

View 'Grid' type

With the Grid' display type, the entries of a container appear as rows in a data grid, i.e. as a list format with the usual Lobster Data Platform / Orchestration functions for sorting, filtering, exporting, etc.

Columns in this list are automatically generated for all elements in the repeated element, which provide content suitable for a list.

Such elements provide further configuration options for the column in the properties section of the same name. The availability of the column-related properties depends on the 'Render as column' option:

Depending on the selection for the Display option, a details area can be displayed above or below the data grid, which, unlike the grid, also allows editing.

Change notices

If Portals enable interactive changes to the ‘list data’ via a Repeatable element container, the processing status of the ‘list’ visible in the form usually has to be ‘synchronized’ with an external data source or processing logic, for example, by transferring the data of the Repeatable element container or the entire form data to a profile or event handler.

In order to make the triggered mechanisms – such as the persistence or synchronization of the ‘list data’ – as flexible, lean and efficient as possible, the Repeatable element container provides the option of using the configuration parameter Field for change notice to designate a data field for the repeated element, in which a change notice is automatically set as a text value by certain processing steps in the form:

For example, if a profile or event handling is executed after a call with the data from a Repeatable element container, it may be useful to assign values to the change notice data field for certain ‘rows’ and return them to the form together with other data. Any text value or ‘no value’ ($null) may be assigned. However, it is also possible to assign one of the predefined change notice values (see table above). The following considerations must be taken into account:

• As long as the change notice created is valid for an instance, the value updated is not set automatically when the instance is updated.

• An instance with the change notice deleted is not visible in the form, but still included in the form data.

►CAUTION◄ The data field linked as Field for change notice should not be assigned to a form element, otherwise an automatically generated change notice may be overridden by its value.

►CAUTION◄ If a Repeatable element container contains Entities with a predefined data structure as entries, an arbitrary additional field cannot simply be defined as a Field for change notice. Finally, it must be possible to parse the data in the list entry as a whole against the data model for the entity type in question. If the Field for change notice is not defined for an entity type used, a change notice is assigned superficially, but is not reproduced when the container is validated. The following scenario illustrates the relationship:

• A Search (Form designer) in a portal returns a list of Company accounts that are assigned to a Repeatable element container as entries via Populate element data.

• For this Repeatable element container, a changeStatus field is designated as a Field for change notice, which is not contained in the data structure for the company.

• If one of the listed Company accounts is removed in the portal, the corresponding entry disappears from the list in the interface. In the background, the value deleted is assigned to the changeStatus field.

• During read access to the list entries, the entry marked as deleted by the changeStatus field is parsed against the data model for Company accounts. The information from the changeStatus field is lost in the process. Effectively, it is no longer possible to determine from the data for the entry that the entry has been deleted, even though it has 'disappeared' from the form.

• If necessary, a text field from the data model of the company account (or e.g. the company address referenced therein) that is not relevant in the context of the portal can be 'reused' as a Field for change notice, the value of which is then overwritten by the text for the change notice.

►NOTE◄ This problem can be easily avoided with a Tuple search (Form designer), which lists 'expandable' client objects instead of entities in the result. However, this means that accessing the associated entities to update data, for example, requires greater effort.

CUD: created

CUD: updated

CUD: deleted

CUD: created

CUD: updated

CUD: deleted