Form dynamism

The Eximee platform enables the design of forms dynamic — responsive to data entered by the user and automatically adjusting their appearance and behavior during completion. The dynamic nature of the form is based on mechanisms that allow dependencies and conditions between fields to be defined. (Implementation details — e.g., expression language syntax or attribute configuration — are described in dedicated chapters Expression language and Listening and clearing, an general introduction is presented below.)

Dynamic form mechanisms

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

• Visibility, activity, and requiredness conditions — defined using a special expression language (syntax based on JavaScript, extended, among other things, with methods getValue() and isVisible() for reading component state). They allow you to determine whether a given component is displayed, active for editing, and required, depending on the values of other fields or variables. Note: Conditions referring to other fields require the listening for those fields to be set up correctly so that changes in their values cause the condition to be re-evaluated.

• Listening (ListeningOn) — an attribute indicating the list of components or variables that a given component “listens” to. A change in the value of listened-to components or variables will trigger recalculation of the defined conditions. Thanks to the listening mechanism, the form responds 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 that specifies the list of components or variables whose value change will cause automatic clearing (reset) of 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 an empty state).

• Conditional rules — additional logic rules executed only when specific conditions are met, allowing more complex dynamic scenarios beyond individual fields to be implemented. We have a number of options for conditioning application actions so that it works in accordance with business assumptions, including:

  • conditions for displaying form steps or pages

  • conditions for invoking services

  • conditions for following a specific process path (business rules)

Applications of dynamic forms

The dynamic behavior of form fields is most often used in situations where user interactions should affect other elements of the form. Typical scenarios include:

• Hiding and showing form elements — dynamically displaying or hiding specific steps, pages, sections, or fields based on previous user selections, data obtained from services, or call parameters. For example, an additional question appears only after the user selects the “Yes” option. Similarly, you can dynamically disable or enable a field’s editability (the editability attribute) depending on whether a condition is met.

• Dynamic value recalculation — automatically calculating or updating 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 ensures immediate execution of the configured scripts whenever input data changes.

• Resetting dependent fields — clearing (resetting) the values of dependent fields after data changes in the indicated component. This prevents outdated or conflicting data from being left in the form. Example: if the “Country” field is changed, the “Province” and “City” fields can be automatically cleared, because their previous values were tied to 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 transfer payment option by bank transfer. Otherwise, this field remains optional. This type of condition prevents validation errors from appearing in situations where a given field does not need to be filled in for a particular scenario.