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., the 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, activity and required conditions – defined using a special expression language (syntax based on JavaScript, extended, among others, with methods getValue() and isVisible() to read component state). They allow determining whether a given component is displayed, editable, and required based on the values of other fields or variables. Note: Conditions that refer to other fields require correct setup of listening to those fields so that changes in their values trigger re-evaluation of the condition.

• Listening (ListeningOn) – an attribute indicating a 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 the defined conditions. Thanks to the listening mechanism the form reacts dynamically to changes – e.g., modifying field A automatically affects field B (causing recalculation of values, change of visibility/requiredness, etc.).

• Clearing (ClearOn) – an attribute specifying a 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 a change in another field – e.g., when a 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 after certain conditions are met, allowing implementation of more complex dynamic scenarios beyond single fields. We have a range of options for conditioning application actions so that it operates according to business assumptions, including:

  • conditions for displaying steps or form pages

  • conditions for invoking services

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

Uses of dynamic forms

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

• Hiding and showing form elements – dynamically displaying or hiding specific steps, pages, sections or fields based on the user's prior choices, data obtained from services or call 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 ensures immediate invocation 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 leaving outdated or conflicting 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 verified by an account number validator) only when the user selects the disbursement option by bank transfer. Otherwise that field remains optional. Such conditions prevent validation errors in situations where a particular field is not required to be filled in for the given scenario.