Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Data model on the interface

Binding form fields to the data model

When the data model is already defined and connected, we can in the application form bind specific fields (UI components) to model fields. In the form editor, every component that stores some value (e.g. a text field, a selection field, a date, etc.) has the property "Data model key".

If the form is connected to the application, the key can be conveniently selected from the list. If the key we need is not on the list, we can enter it manually.

Figure 1. Selecting a data model key from the list (with manual entry available)

After selecting the key, the data from the component is bound to the appropriate place in the model. From that moment on, the component becomes two-way bound (two-way binding) with the data model – during form initialization the value from the model (if it exists) will be loaded into the field, and when the user fills in or changes this value, it will be written back to the data model when the application is saved. This means that after saving the form, all bound fields update their corresponding values in the data model, so the model always reflects the current state of the application's data.

Figure 1. Example of two-way binding using the data model key

Info: One can also use one-way binding of a field to the model in situations where we only want to display a value from the model on the form, but not update it based on user input. Such a one-time read is implemented, for example, by inserting a reference to a model variable into text (labels) or using the component property valueSourceId, which will fetch the value from the model in read-only mode only. By default, however, for editable fields we use two-way binding so that the entered data is saved.

Figure 2. Example of one-way binding using valueSourceId

Remember that not every form component can be bound to the model. The data model only makes sense for fields that store values. Therefore, we will not bind to the model elements such as:

  • links (hyperlinks),

  • CAPTCHA fields,

  • single radio buttons (outside radio button groups),

  • popup windows,

  • QR codes (if they appear as an image/decorative element).

All other fields (text, numeric, list selections, checkboxes, dates, sections, etc.) can and should be bound to the data model if their value is to be preserved or used outside the form itself. This binding ensures consistency – every piece of data entered by the user has its place in the model, from where it can be further processed (e.g. passed to the process).

Values from the data model can be used in the Content (TextContent) artifact, e.g.

Handling array fields (lists)

The data model allows defining fields that are collections (arrays) of objects or simple values. If, in the model, a given field is to have multiple repetitions (e.g. a list of addresses, a list of products, etc.), its multiplicityMax > 1 (e.g. null for no upper limit) and prepare an appropriate data source returning a collection. In the form, such a field can be represented for example by a Repeatable Section (Repeatable Section) with the appropriate fields inside. It is important to properly refer to array elements in the model keys:

  • collection[].field – reference to all occurrences of the field in the collection (returns the entire list of values or e.g. concatenation, depending on the context),

  • collection[0].field – reference to the field in the first element of the collection (index 0 means the first element, 1 - the second, etc.),

  • Note: The index cannot be omitted! The syntax collection.field (without [] [] or an index) is invalid and will cause an error preventing the form from starting. You must always use array notation when referring to fields of collection elements.

  • For repeatable sections in the form, where the user can dynamically add/remove elements, Eximee uses the variable _rowIdx assigned to a given section, to pass the index of the current row. The model key then takes the form NazwaSekcji_rowIdx. For example, if the repeatable section is bound to collection products[] and has field name, then the field key in the section can look like: products[NazwaSekcji_rowIdx].name. This mechanism ensures that each dynamically added field is bound to a unique index in the model.

Figure 3. Binding an array field to a repeatable section
Figure 4. Binding a Combobox located in a repeatable section to the data model

Using the model in the Data Quality tab

You can use keys from the data model in the Data Quality tab to define visibility, requiredness, or activity conditions.

However, remember that if a given field listens for changes in another field, each such reference will trigger a re-query to the data model, which can negatively affect performance. In such cases, it is recommended to retrieve the value from the data model into a variable and use that variable in conditions, which avoids unnecessary references to the model.

Figure 5. Visibility condition using the data model

dataModelTransformer

Thanks to dataModelTransformer, located in XML (the "Source" tab), you can influence the data that will flow into the data model after the application is saved.

To use this functionality, you need to add a script in XML (in ecMetadata inside iftTemplateMetadata) that can modify the model being saved.

Example of mapping session variables to the data model:

Example mapping of values from invisible fields to the data model:

PreviousComplex validations (custom)
NextPopulating values from external sources

Last updated

Was this helpful?