Form fields
Every kind of field an auto-generated editor can show, from the schema alone, and from Tessryx's few UI hints.
Every editor in Tessryx is drawn from a schema. You don't configure any of this (your agent designs the data and the right control appears), but it's worth knowing the range, because it's wide. This is the catalog.
There are two sources for a field's control. The schema itself decides almost everything: its types and standard JSON Schema keywords map straight to rich inputs. A small set of Tessryx hints covers the handful of things standard JSON Schema simply can't express. The order matters, and it's a deliberate rule. See the last section.
#What the schema alone gives you
No hints, just ordinary JSON Schema. This is the bulk of every form.
| When the schema says… | You get… |
|---|---|
type: string | a text box (a textarea when it's long) |
format: email | an email input |
format: uri / url | a URL input |
format: date / date-time / time | a date picker / date-and-time picker / time picker |
format: uri-template | a URI-template input that understands its {variables} |
enum (a fixed set) | a dropdown (radio buttons for a short set) |
const | a fixed, display-only value |
writeOnly: true | a masked, password-style input (for secrets: the value isn't shown back) |
readOnly: true | the field, shown but locked |
contentMediaType: text/markdown | a Markdown editor with a formatting toolbar |
contentMediaType: text/html | a rich WYSIWYG editor |
contentMediaType: application/jsonata | a JSONata editor with live syntax checking |
contentMediaType: a known code type (JSON, Python, protobuf, …) | a code editor with syntax highlighting |
type: number / integer | a number input |
a number with minimum + maximum (and a step) | a slider |
type: boolean | a toggle |
type: array | an add/remove list |
an array of enum values | a multi-select |
type: object | a nested section (its own little form) |
additionalProperties / patternProperties with a schema | a key/value map editor |
oneOf / anyOf | a variant chooser, a dropdown that swaps the fields beneath it |
That's a full-featured editor out of an honest schema: pickers, sliders, toggles, rich text, code, maps, nested sections, and variant switches, all correctly typed and labelled.
#Structure runs as deep as your data
The table lists the controls; the real power is how they nest and react. A schema isn't a flat list of fields. It's a shape, and the form takes on that whole shape.
Lists (arrays) are far more than rows of text. An array's items can be anything, and the list gives you an editor for that thing, repeated:
- a list of objects → each row is its own little form, so a "team members" array becomes a stack of name / role / photo sub-forms you add, edit, and reorder.
- a list of lists → nested lists, as deep as the schema goes.
- an array of a fixed set of choices → a multi-select instead of rows.
- a tuple (position 1 a string, position 2 a number, …) → a fixed row of differently-typed fields.
- no duplicates (unique items, or unique by a chosen property) is enforced as you type.
Sections (objects) nest the same way: an object inside an object inside an array is just sections within sections. A section whose fields are all simple values renders as a tidy inline group; one with real sub-structure gets its own titled, collapsible card, so a big record stays navigable instead of becoming a wall of inputs.
Maps handle open-ended keys: "a value per country code," "a setting per feature." You add key/value pairs, and the value gets a proper typed editor from the schema (a map of objects gives you a sub-form per entry). Where the schema pins down which keys are allowed, ones that don't fit show as removable rather than editable.
Choices (either/or) are the switch. "This is either a link or an uploaded image or an embed" becomes a dropdown that swaps the entire sub-form to match the option you pick, and when the schema names one field as the discriminator, the form uses it as the label.
Fields that appear when they're relevant. A schema can say "if delivery is 'shipping', then also ask for an address," and the form honors it live: the address fields appear the moment you choose shipping, and clear themselves when you don't. These conditions nest and stack, so a form can reshape itself as you fill it in, only ever showing what matters.
Sensible starting values. Where the schema defines a default, the field starts there, even a default that only applies inside a branch that just appeared. You begin from a filled-in, valid-shaped form, not a blank one.
Underneath all of it, validation runs as you type (required fields, formats, ranges, uniqueness, allowed values), surfaced as inline hints. They're guidance, not gates: you can always save a work in progress, and the server is the final word.
That's the wild part. From one honest schema you don't get a form. You get a typed, nesting, self-adjusting editor that mirrors the exact shape of your data.
#The Tessryx hints
For the few things JSON Schema has no vocabulary for, a schema can carry an
x-tessryx-ui.input hint (with an optional options object). These are the complete set:
| Hint | You get… |
|---|---|
"cron" | a schedule editor: you type a cron expression and see it in plain English plus its next run times. options.timezoneFrom points at a timezone field elsewhere in the form so the preview honors it. |
"timezone" | an IANA timezone picker (stores e.g. America/New_York). |
"lookup" | a reference picker that links this record to another. options.from searches within the current document; options.resource browses a chosen kind of resource elsewhere. |
"media-upload" | the media picker: browse your Media library or upload a file inline. |
"slug" | a slug field that can auto-derive from another field (options.source, options.separator). |
"color" | a color picker. |
"schema-form" | a form-within-a-form: it reads another field's schema and renders that as a form (e.g. an endpoint's inputs, taken from the workflow it runs). |
All the editors accept an options.height to size them; the code hint also takes
options.language.
#Overrides
A hint can also force or suppress a control the schema would otherwise infer, for the rare case the default isn't what you want:
"markdown","html","jsonata","code"force that editor even without the matchingcontentMediaType."text"/"textarea"force a plain box, suppressing an inferred rich editor."slider"/"input"force or suppress a number slider.
#Why the hints are the exception
The rule your agent follows: reach for a standard JSON Schema keyword first, and a
x-tessryx-ui hint only when nothing standard can say it. Notice how short the hints list is,
and what's on it: cron, timezone, cross-record links, the media library, a slug derived from
a sibling. None of those has a standard keyword; that's the only reason they're a hint. A
Markdown editor, a slider, a variant chooser, a masked secret: all of those come from the
schema itself, so they never need one.
This isn't fussiness. Keeping schemas on standard ground means they stay portable and predictable, they validate the same everywhere, and the AI agents that author them are working in a language they already know rather than a house dialect. The payoff for you is that the editor "just appears," correctly, from a schema that says exactly what your data is, with the hints doing the small, honest job of filling the last few gaps.