Eighteen field types the model already knows about

The fields layer turns a model column into a form input, a list cell and a validator at once. Eighteen types ship on one abstract base: text, number, price, date, datetime, bool, email, password, select, multiselect, file, image, wysiwyg, token, virtual, and the relational parent, child and many.

The reason to have them is that the same fact about a column gets restated in three places otherwise. A price is a decimal in the schema, an input with a step and a currency prefix in the form, a right-aligned formatted string in the list, and a validation rule on submit. Four descriptions of one thing, kept in sync by hand, drifting whenever one is edited without the others.

A field type is that one description. It knows how to render itself for editing, how to render itself for display, how to parse what comes back, and what counts as valid. The CMS builds its whole admin from it, which is the honest test: if a schema can produce a working admin without extra description, the description was complete.

The relational three are where it earns most. parent renders as a select over another model, child as a nested list under its owner, and many as a multiselect over a join. Those are the parts people hand-write most often and get subtly wrong most often.

virtual is the deliberate escape hatch: a field with no column behind it, returning ready-made markup, for the cases where a computed cell is genuinely what you want.

Engine 1.0. See fields in the manual.