Form dynamism

The Eximee platform enables the design of forms dynamic – that react to data entered by the user and automatically adjust their appearance and behavior during completion. The dynamism of a form is based on mechanisms that allow defining dependencies and conditions between fields. (Implementation details – e.g. expression language syntax or attribute configuration – are described in dedicated chapters Expression Language and Listening and clearing, an overview is presented below.)

Dynamic form mechanisms

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

• Visibility, enabled state and requiredness conditions – defined using a special expression language (syntax based on JavaScript, extended, among others, with methods getValue() and isVisible() to read the state of components). They allow you to make whether a given component is displayed, editable, and required dependent on the values of other fields or variables. Note: Conditions referring to other fields require proper configuration of listening to those fields 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 values of listened-to components or variables will trigger recalculation of defined conditions. Thanks to the listening mechanism, the form reacts dynamically to changes – e.g. modification of 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 value change will cause automatic clearing (reset) of the value of a given field. The clearing mechanism removes data that has become outdated or undesirable after another field changes – for example, when the user changes a choice in a parent field, dependent fields with ClearOn set will be emptied (restored to an empty state).

• Conditional rules – additional logic rules executed only after certain conditions are met, allowing implementation of more complex dynamic scenarios that go beyond single fields. We have a number of options for conditioning application actions so that it operates according to business assumptions, including:

  • conditions for displaying form steps or pages

  • conditions for invoking services

  • conditions for proceeding along a specific process path (business rules)

Uses of dynamic forms

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

• Hiding and showing form elements – dynamically displaying or hiding certain steps, pages, sections or fields based on the user's previous selections, data obtained from services or invocation parameters. For example, an additional question appears only after the user selects the “Yes” option. Similarly, the ability to edit a field (editability attribute) can be dynamically disabled or enabled depending on whether a condition is met.

• Dynamic recalculation of values – 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 configured scripts whenever input data changes.

• Resetting dependent fields – clearing (resetting) the values of dependent fields after data in the specified component changes. This prevents outdated or conflicting data from remaining in the form. Example: if the “Country” field is changed, the “State/Province” and “City” fields may 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 certain situations. For example, the “Account number” field can be marked as required (and validated by an account number validator) only when the user selects the payout option bank transfer. Otherwise that field remains optional. Such conditions prevent validation errors from appearing in situations where a given field is not required to be filled in that scenario.