Generation variables

A template doesn’t know your project. Generation variables are the bridge: the template declares the variables it needs, and you fill in their value in Restorm. At generation time, each value is evaluated then injected into the template context.

Variable or native flag?

Only use a variable for what the design doesn’t already carry. The intentions you entered in the design (searchable, PII, volume, access pattern, traffic, freshness, sensitivity, retention, cache, authentication…) are directly readable in the template via ctx — no need to redeclare them. See The template context. Variables are for the settings specific to the template: package name, namespace, framework version, whether to generate a Dockerfile or not, etc.

Declare and fill in

Each variable is declared by the template (in its restorm-template.json) with a name, a scope, a type, a default value and an optional description. On the Restorm side, you fill in its value as a Handlebars expression — evaluated for each entity concerned, then converted to the declared type.

The possible types are string, boolean, number and enum (with its list of options).

A Discover the variables used by this template action analyzes the template and flags the variables used but not declared, to avoid oversights.

The scopes

The scope decides at which level the variable is evaluated and where it lands in the template context:

Scope	Evaluated	Available in the template
Project	once	ctx.design.vars.<name>
Model	per model	ctx.models[].vars.<name>
Property	per property	ctx.models[].properties[].vars.<name>
Route	per route	ctx.groups[].routes[].vars.<name>

General value and override

For each template, you define general values by scope (the “general variables”, which apply for example to all models). You can then override a variable for a given model, property or route, from the entity’s Code generation tab. An empty value means “inherit”: the first non-empty value wins, and any unresolved value surfaces as an error — never silently.