Breadcrumbs

Model Evaluation Configurator Logic

The tab type Configurator is superseded. Since version 17.1, Model Class evaluation tabs should use a Form type and form logic (Forms 2.0) instead of the Configurator-based approach described further down this page. See Forms 2.0 and its child pages, in particular How to Convert Legacy Inputs to Forms. The Configurator-based content below is kept for reference when working with older Model Classes that haven't been migrated yet.

Using Forms in a Model Class Tab

The best way to do the following steps in Model Class editor in Studio.

To build the input fields of a Model evaluation tab with Forms 2.0:

  1. In the Model Class Tab definition, set the tab's type to form (rather than configurator).

  2. Create a Form logic and reference it from the tab's formulaName.

  3. Implement the standard Form phases in that logic:

    • Init – define the initial set of inputs for the tab. Replaces the old pattern of returning ConfiguratorEntry sections from visible elements.

    • ValueOptions – supply value options for OPTION / OPTIONS inputs lazily, instead of embedding them upfront.

    • Action – react to user changes (add/remove inputs, reload options, validate, show messages), replacing the old full-logic re-execution on every input change.

  4. As with the legacy Configurator logic, the Form logic for a Model class tab still receives the model binding variable (see Model Context), giving access to the Model table, inputs from previous steps, and outputs from previous calculations – in addition to the current tab's input values. The Logic Nature stays model_evaluation; only the input-building approach changes (Form API instead of Configurator API).

For the general conversion steps (replacing api.inputBuilderFactory(), addToConfiguratorEntry(), row/collapsible layouts, etc.), follow How to Convert Legacy Inputs to Forms – the same conversion steps apply here as for any other configurator-based logic, plus the model variable stays available in the Form logic's Init/ValueOptions/Action elements.

For the full Form API (creating inputs, layout, validation), see Forms 2.0 - API Reference.

Legacy Approach: Configurator-based Model Evaluation Logic

The content below describes the pre-17.1 Configurator-based approach. It is kept for reference when maintaining Model Classes that haven't been migrated to Forms yet. For new implementations, use the Form-based approach described above.

This logic defines a page content of a tab with the type configurator which provides the user with a tab with many input fields whose values typically depend on each other. So this logic builds the Configurator form with dynamic input fields.

This logic is almost identical to (archived) – the only difference is that it also gets the binding variable model – so we will describe here just the specifics of this evaluation configurator logic.

Logic API

  • Logic Nature: model_evaluation

  • Execution Types:

    • Standard – Builds the input fields based on the model's current tab inputs, previous steps inputs and previous calculations outputs.

  • Information provided to the logic:

    • Standard:

      • model (see ModelEvaluationFormulaContext) – Includes Model table, inputs from previous steps and outputs from previous calculations.

      • input – Values of all inputs from the current tab, provided by the user.

  • Expected logic execution outcome:

    • Form's sections and input fields – provided via the output of visible element logic.