A constraint is a rule attached to a model property. Constraints have two purposes: they tell Yellow how to display the property in forms and tables, and they tell Yellow what values are valid when an instance is saved.

Constraints live inside a view, so the same property can have different rules for the creation form, the edit form, the table listing, and so on. When a view does not define a particular constraint, Yellow falls back to the default view.

Display constraints

Every property carries one display constraint. It controls layout, not values.

Field What it does
visible Whether the property appears in the form or table at all.
order The position of the property among its siblings.
readonly Disables editing while still showing the value.
flex Width hint: how much horizontal space the property takes in its row.
group Optional section label used to bundle related properties together.

Display constraints are what most users tweak day-to-day: hide audit fields on the create form, reorder columns in the table view, mark calculated fields as read-only on update, and so on.

Value constraints

Beyond display, Yellow ships typed constraints that validate the value itself. The available type depends on the property's type:

String constraints

For text properties.

  • Required — the field cannot be empty.
  • Minimum length / Maximum length — character bounds.
  • Minimum lines / Maximum lines — for multi-line text.
  • Regular expression — a regex pattern the value must match.
  • Mail — when enabled, the value must be a well-formed email address.
  • Edit widget — picks the editor used in the form (single-line input, text area, e-mail, etc.).

Integer constraints

For whole-number properties.

  • Required — the field cannot be empty.
  • Minimum / Maximum — numeric bounds (inclusive).
  • Enumeration — restrict the value to a list of predefined items, shown as a dropdown.

Datetime constraints

For date and time properties.

  • Required — the field cannot be empty.
  • Display mode — whether the picker shows date only, time only, or both.

Instance reference constraints

For properties that point to another instance.

  • Required — the reference cannot be empty.
  • Target model — the model the reference must point to.
  • Owned — when true, the referenced instance is owned (composition): deleting the parent deletes the child. When false, it is a plain reference.
  • Filter — a dynamic filter expression that limits the candidate instances shown to the user.

Collection constraints

For properties that hold a collection of items.

  • Minimum count / Maximum count — bounds on the number of elements.
  • Target model — the model of the items in the collection.
  • Item type — what kind of element the collection holds (instance reference, property, etc.).

Per-view constraints

A typed constraint can be defined globally (in the default view) or per view (e.g. only in create). The most common pattern is:

  1. Define the strict rules in the default view — for instance, email must be required and match a regex.
  2. Override per view only when needed — for instance, make a system field read-only and hidden in create but visible and read-only in update.

If a view does not define a typed constraint for a property, Yellow uses the constraint from the default view. If the default view has no constraint either, no validation is enforced for that property beyond what the type itself guarantees.

Where to edit constraints

Open the model from the Explorer. In the properties editor, pick a view from the Views selector and click a property to edit its display constraint and (if available) its typed constraint. Save to publish the changes; instance forms across the application pick up the new rules immediately.