Radio
- Version
- 3.x
- Updated
One value from a small set, rendered as radio buttons.
Storage kind: column · Column: varchar(50)
Use it when the set is short — three or four options — and the operator benefits from seeing all of
them at once without opening anything. Beyond that, dropdown: a radio group of
twelve options is a wall.
Settings
| Setting | Meaning |
|---|---|
choices | value => label map |
radios | Legacy alias for the same thing |
default | Pre-selected value |
choices wins; radios is only consulted when choices is empty. They are alternatives, not
merged.
How it differs from dropdown
Less than you would expect, and in one place more than you would expect.
Storage is identical — the same varchar(50), the same short-token keys. Rendering differs. But
radio is not a subclass of dropdown, and it does not carry dropdown's two extras:
- it does not validate membership in
check(), so an out-of-set value is stored; - it does not filter with exact match, so list filtering uses the base substring
LIKE.
getValueSet() does read choices, so a static set still publishes an enum to the generated JSON
and MCP schemas — which means a schema-driven caller is constrained even though check() would not
have stopped a hand-crafted POST.
If you want the validation, use dropdown. If the radio presentation matters and the input is
untrusted, validate in the model's validateData().
getValueSet() reads choices, then the legacy radios, so either spelling publishes an enum.
It used to read choices only — a definition using radios rendered and stored fine while
documenting itself as an unconstrained string. Prefer choices in new definitions all the same.
@see dropdown.md