> 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/dynamicznosc-formularza.md).

# Dynamic forms

The Eximee platform enables the design of forms **dynamic** – responding to data entered by the user and automatically adapting their appearance and behavior during completion. The dynamic nature of a form is based on mechanisms that allow dependencies and conditions between fields to be defined. (Implementation details – e.g. the expression language syntax or attribute configuration – are described in dedicated chapters [**Expression language**](/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/dynamicznosc-formularza/jezyk-wyrazen.md) and [**Listening and clearing**](/documentation/documentation-en/budowanie-aplikacji/interfejs-uzytkownika/formularze/dynamicznosc-formularza/nasluchiwanie-i-czyszczenie.md)**,** below is a general introduction.)

### Dynamic form mechanisms

The most important elements responsible for the dynamic behavior of a form are:

* **Visibility, activity, and requiredness conditions** – defined using a special expression language (syntax based on JavaScript, extended e.g. with methods `getValue()` and `isVisible()` for reading component state). They make it possible to make whether a given component is displayed, active for editing, and required depend on the values of other fields or variables. *Note:* Conditions referring to other fields require the listening of those fields to be set up correctly so that changes to their values trigger re-evaluation of the condition.
* **Listening (ListeningOn)** – an attribute indicating the list of components or variables that a given component “listens to.” Changing the values of listened-to components or variables will cause the defined conditions to be recalculated. Thanks to the listening mechanism, the form reacts dynamically to changes – e.g. modifying field A automatically affects field B (causes recalculation of values, changes in visibility/requiredness, etc.).
* **Clearing (ClearOn)** – an attribute specifying the list of components or variables whose change in value will automatically *clear* (reset) the value of a given field. The clearing mechanism removes data that has become outdated or unwanted after another field changes – e.g. when the user changes the selection in a parent field, dependent fields with ClearOn set will be emptied (restored to the empty state).
* **Conditional rules** – additional logic rules executed only when specific conditions are met, allowing more complex dynamic scenarios beyond single fields to be implemented. We have at our disposal a range of possibilities for conditioning application actions so that it operates in accordance with business assumptions, including:
  * conditions for displaying form steps or pages
  * service invocation conditions
  * conditions for following a specific process path (business rules)

### Applications of dynamic forms

Dynamic behavior of form fields is most often used in situations where user interactions should affect other elements of the form. Typical scenarios include, among others:

* **Hiding and showing form elements** – dynamically displaying or hiding specific steps, pages, sections, or fields based on previous user choices, data obtained from services, or invocation parameters. For example, an additional question appears only after the user selects “Yes.” Similarly, the ability to edit a field (the editability attribute) can be dynamically disabled or enabled depending on whether a condition is met.
* **Dynamic recalculation of values** – automatic calculation or updating of the value of one field based on the values of other fields. For example, the total in the "Total income" field can be calculated from the values in the "Income 1" and "Income 2" fields. The listening mechanism guarantees immediate execution of the configured scripts whenever the input data changes.
* **Resetting dependent fields** – clearing (resetting) the values of dependent fields after data changes in the specified component. This prevents outdated or inconsistent data from remaining in the form. Example: if the "Country" field is changed, the "Region" and "City" fields can be automatically cleared because their previous values were associated with the previously selected country.
* **Conditional validation** – checking the correctness or requiredness of fields only in specific situations. For example, the "Account number" field may be marked as required (and verified by the number validator) only when the user selects the payout *by bank transfer*. Otherwise, this field remains optional. Such conditions prevent validation errors from appearing in situations where a given field does not need to be completed in a particular scenario.


---

# 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/dynamicznosc-formularza.md?ask=<question>&goal=<endgoal>
```

`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.