Comparison of Static Inputs, Configurator API and Form API

This page summarizes the differences between Forms 2.0 and the legacy static inputs and configurators. It focuses on the most common decision points: when inputs are created, how dynamic behavior works, how options are loaded, what gets persisted, and what the impact is on UX, maintainability, and validation.

Lifecycle and Dynamic Behavior

Question

Static Inputs API

Configurator API

Form API

When are inputs created?

Created once during input generation / syntax check.

Rebuilt from scratch on every configurator logic execution.

Created once in Init mode.

Can the form be changed dynamically?

No.

Yes, but only by rebuilding the full configurator each time.

Yes, inputs can be added, updated, or removed in Action mode without rebuilding the whole form.

Are line-item inputs supported in a grid?

Yes.

No, due to performance impact of executing logic for every line item.

Yes.

Option Loading and Persistence

Question

Static Inputs API

Configurator API

Form API

How are OPTION / OPTIONS values loaded?

Statically, at input creation time.

Dynamically on every configurator execution, with all options repopulated each time.

Dynamically after display and again on demand when explicitly reloaded through Action mode.

Are option values persisted in the object?

Yes.

No, they are populated on the fly.

No, they are populated on the fly.

Are input definitions persisted in the object?

Yes.

No, only values are persisted.

Yes.

Will options refresh when the object is reopened?

No, persisted options are reused.

Yes.

Yes.

Reuse, Maintainability and Validation

Question

Static Inputs API

Configurator API

Form API

How can the form logic be reused?

By extracting shared logic into a Groovy library function and calling it from input generation code.

By referring to the same configurator logic from pricing logic.

By selecting the same form logic in the pricing logic definition.

Is the implementation easy to maintain?

Generally yes for simpler use cases.

Often no; implementations can become large and fragile.

Generally yes; responsibilities are separated into creation, data retrieval, and actions.

Is custom validation supported?

No, validation happens only after submission in pricing logic.

Yes, messages can be added.

Yes, error and warning messages can be raised in Action mode.