Designing a form
A model with the right properties is only half the work — the form your users actually fill in comes from the model's views and constraints. This walkthrough shows the most common form-design tasks: hide system fields on creation, mark calculated fields read-only on edit, group related fields visually, and lay them out side by side.
We assume a Customer model with these properties: name, email, taxId, notes, createdOn, updatedOn.
1. Hide audit fields on the create form
createdOn and updatedOn are filled automatically — users should not see them when creating a customer.
- Open the
Customermodel in the Explorer. - Pick the create view from the Views selector.
- Click
createdOn. Set the display constraint tovisible = false. Save. - Repeat for
updatedOn.
The default view stays unchanged, so other places that do not override (the edit form, the table) keep showing the fields.
2. Show audit fields read-only on the edit form
For an existing record, the audit fields should be visible — just not editable.
- Pick the update view from the Views selector.
- Click
createdOn. Setvisible = true,readonly = true. Save. - Repeat for
updatedOn.
Now the edit form shows when and by whom the customer was created and last updated, but the user cannot change those values.
3. Make a field required only when creating
You can require email on creation but allow it to be empty when editing legacy records.
- Pick the create view.
- Click
email. Add a String constraint withrequired = true. Save. - Pick the update view.
- Click
email. Add a String constraint withrequired = false. Save.
The default view's constraint, if any, is used only when neither create nor update overrides it.
4. Group related fields with a section
Visual grouping makes long forms readable.
- Pick the default view (so the grouping applies everywhere).
- On each property, set the display constraint's
groupfield to a label:name,email,taxId→ groupIdentification.notes→ groupNotes.
- Order the properties:
name(1),email(2),taxId(3),notes(10),createdOn(20),updatedOn(21).
The form now shows two collapsible sections with the properties in the right order.
5. Use flex to lay out fields side by side
By default each property occupies its own row. The flex display constraint controls how much horizontal space a property takes when several share a row.
name→ flex2email→ flex2taxId→ flex1
Inside the Identification group, these three properties now share one row with taxId taking less space than the other two.
6. Preview the result
Open the Explorer and create a new Customer. The create form should:
- Not show
createdOnorupdatedOn. - Require
email. - Show
name,email,taxIdon one row, thennotes, all under labeled sections.
Open an existing customer and switch to the edit form. The audit fields should now be visible at the bottom, read-only.
Related
- Views — built-in tags (
create,update,table) and the default-view fallback. - Constraints — display and value constraints, full list.
- Dynamic filters in instance constraints — next step when references need context-aware lists.