Form Schema

A form system stores at least two different things. The definition describes how to render, validate, and eventually persist a form. The data is the object a user creates by filling that form in.

The split is similar to the model described in Form.io's schema/submission model: the definition and the submitted values are related, but they should not be stored as one thing.

DOM Studio uses a typed form definition as the practical authoring format. It can normalize to renderable children and project toward JSON Schema when a portable data contract is needed.

A database table is often enough to generate a useful first form: strings become text inputs, booleans become toggles, dates become date pickers, required columns become required fields. Product teams can then add richer UI context: labels, help text, grouping, conditional visibility, validation messages, and component choices that the raw database cannot know.

The reverse should also work. A form builder can let someone pick front-end components, and each component can contribute a sensible storage default. That form definition can generate table metadata or migrations later.

// Database first.
const userTable = {
	name: 'users',
	columns: [
		{ name: 'name', type: 'varchar', length: 150, nullable: false },
		{ name: 'email', type: 'varchar', length: 254, nullable: false },
	],
};

const formDefinition = createFormDefinitionFromTable(userTable);

// Form builder first.
const tableSchema = createTableSchemaFromForm(formDefinition);

Components should eventually know how their values travel through the system. The browser value, the submitted form value, and the database value are usually close, but they are not always identical. Keeping conversion functions near the field definition makes that lifecycle explicit.

const textFieldDefinition = {
	type: 'string',
	component: 'DomTextInput',
	storage: {
		type: 'varchar',
		length: 150,
	},
	fromDatabase(value) {
		return value ?? '';
	},
	toDatabase(value) {
		return String(value || '').trim();
	},
};

Right now, DOM Studio concentrates on the frontend contract: DomForm normalizes typed definitions into renderable children and stores user input in v-model.

The next layer can add storage metadata without changing that core relationship. The form definition remains the master UI definition; JSON Schema can represent the portable data contract; the data remains the values; server adaptors can translate between the definition and real database tables when that part of the stack is ready.