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:
In the Model Class Tab definition, set the tab's
typetoform(rather thanconfigurator).Create a Form logic and reference it from the tab's
formulaName.Implement the standard Form phases in that logic:
Init – define the initial set of inputs for the tab. Replaces the old pattern of returning
ConfiguratorEntrysections from visible elements.ValueOptions – supply value options for
OPTION/OPTIONSinputs 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.
As with the legacy Configurator logic, the Form logic for a Model class tab still receives the
modelbinding 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'sinputvalues. The Logic Nature staysmodel_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 Form Logic (Configurator Reference)Archived (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_evaluationExecution 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.
Tab type Forms should be used since 17.1.
https://pricefx.atlassian.net/browse/PFUN-34968