Form dynamism

The Eximee platform enables the design of forms dynamic – that respond to data entered by the user and automatically adjust their appearance and behavior while being filled out. 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, a general introduction is presented below.)

Dynamic form mechanisms

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

• Visibility, activity and required conditions – defined using a special expression language (syntax based on JavaScript, extended e.g. with methods getValue() and isVisible() for reading 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 correct 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. Changing the values of listened-to components or variables will trigger re-calculation of the defined conditions. Thanks to the listening mechanism, the form reacts dynamically to changes – e.g. modification of field A automatically affects field B (causes re-calculation of values, change of visibility/requiredness, etc.).

• Clearing (ClearOn) – an attribute specifying the list of components or variables whose value change will automatically clear (reset) the value of a given field. The clearing mechanism removes data that has become outdated or undesirable after a change in another field – e.g. when a user changes a 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 certain conditions are met, allowing implementation of more complex dynamic scenarios that go beyond individual fields. We have a number of options for conditioning application actions so that it operates according to business assumptions, including:

  • conditions for displaying steps or form pages

  • conditions for calling services

  • conditions for taking 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:

• Hiding and showing form elements – dynamically displaying or hiding certain 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 the “Yes” option. Similarly, the ability to edit a field (the editability attribute) can be dynamically disabled or enabled depending on whether a condition is met.

• Dynamic value calculation – 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 guarantees immediate invocation of configured scripts whenever input data changes.

• Resetting dependent fields – clearing (resetting) the values of dependent fields after a change in the specified component. This prevents leaving outdated or inconsistent data in the form. Example: if the "Country" field is changed, the "State" 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 may be marked as required (and validated by an account number validator) only when the user chooses the payout option by 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 for a particular scenario.