Dynamic Configuration System

CodeSCE modules are configured through a form, not code edits. Authors describe a module's settings as a config schema, and the Dynamic Form Engine renders that schema into an interactive form — the same one used for the module-page preview and for the buyer after purchase.

How variables work

A config schema is plain JSON: sections, each containing variables. Every variable declares its name, label, type, and options.

{
  "sections": [
    {
      "title": "Appearance",
      "description": "Look and feel",
      "variables": [
        {
          "name": "accentColor",
          "label": "Accent color",
          "description": "Primary brand color",
          "type": "color",
          "default": "#6d5efc"
        },
        {
          "name": "buttonRadius",
          "label": "Corner radius",
          "type": "slider",
          "min": 0,
          "max": 24,
          "default": 8
        },
        {
          "name": "showLabels",
          "label": "Show labels",
          "type": "boolean",
          "default": true,
          "required": false
        }
      ]
    }
  ]
}

Each variable supports these fields:

Field	Purpose
name	The key the value is returned under (required).
label	Human-readable title shown next to the control.
description	Optional helper text.
type	Which control to render (see below).
default	Pre-filled value.
required	Whether a value must be provided.
options	Choices for select / radio.
min / max	Range bounds for slider.

Supported field types

The engine ships with seven control types — adding one is a single-line change in the renderer:

type	Control
text	Text input
number	Numeric input
boolean	Toggle switch
select	Dropdown
radio	Radio group
slider	Range slider with min/max
color	Color picker with hex

Form Engine overview

The Form Engine is frontend-only and dependency-free, following the repo's shared-module pattern — classic <script defer> files that attach to window (no build step, no ES modules). It has three parts:

Module	Global	Role
schemaStore	window.CodeSCESchemaStore	Save / load / clear the working schema (client-side bridge from Studio to the config screens).
validators	window.CodeSCEValidators	Reusable validation (e.g. required-field checks).
formRenderer	window.renderDynamicForm	Turns a schema into the form UI.

Rendering is simple:

renderDynamicForm(container, schema, function (values) {
  // values = { accentColor: "#6d5efc", buttonRadius: 8, showLabels: true }
});

The generated markup mirrors CodeSCE's native controls (cards, rows, switches, custom dropdowns, sliders) and is style-scoped so it never leaks into a page's own controls.

One schema, one renderer, everywhere

The author builds the schema in Studio; the exact same engine renders it for the module-page preview and for the buyer's configuration after purchase. What you design is precisely what the buyer sees.

User overrides

After purchase, the buyer opens the configuration form, adjusts the variables, and submits. The engine:

1. Validates the inputs (required fields must be filled; a boolean always has a state, so it's never "empty").
2. Collects values into a flat object keyed by each variable's name.
3. Hands them to the module — these are the buyer's overrides, layered on top of the author's defaults.

The result is the buyer's own configured instance of the module, without ever touching the source code.

Next step

See how a configured module drops into a project in Integration Model →.