> For the complete documentation index, see [llms.txt](https://docs.eximee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/praca-z-komponentami-bazowymi/model-danych-na-interfejsie.md). # Data model in 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

{% hint style="info" %} **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. {% endhint %}

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. {% code expandable="true" %} ```java

Example content ${model:client.name}

``` {% endcode %} ### 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: {% code expandable="true" %} ```java function transform(input) { input.put('bazaOfert.KredytNr', api.form.v1.value("agreementId")); input.put('bazaOfert.CIF', api.form.v1.value("cif")); if(api.form.v1.value("GesCheckbox5") == "false"){ input.put('daneKlientaCis.NumerTelefonu', api.form.v1.value("phoneNumber")); input.put('daneKlientaCis.AdresEmail', api.form.v1.value("email")); } return input; } ``` {% endcode %} Example mapping of values from invisible fields to the data model: {% code expandable="true" %} ```java function transform(input) { for (let node of api.form.v1.invisibleFormNodes()) { if(node.model()) { input.put(node.model(), ''); } } return input; } ``` {% endcode %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/praca-z-komponentami-bazowymi/model-danych-na-interfejsie.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.