Skip to content
MoltaroMoltaroMoltaro Docs

UI surface library

The Surface library tab manages the reusable leaf surfaces of a record type: tables, cards, and forms. Runtime screens select these surfaces, so the same record type looks and behaves consistently in a detail page, drawer, list, board, or related section.

Surfaces

Section titled “Surfaces”

A Table Surface, including the default, can own a Parent Tree View. It follows one indexed scalar self-Reference. Every table host renders the effective surface presentation; reference inputs require the full Lookup picker for Tree.

  • Tables — explicit grid configurations. One table is starred as the default grid.
  • Cards — summary cards with configured items.
  • Forms — field layouts for create and edit.

Each surface is a saved, named configuration with a stable key. Surfaces can be generated from the schema, created manually, cloned, and deleted. One surface per type is the default, used whenever a runtime screen’s selector does not pick a specific one.

Card Fields, TextBlocks, and Alerts can set a responsive Column span. The same Card may use fewer columns in a narrow Drawer and more columns on Details, so the value is clamped to the space that currently fits. Field types do not become full-width automatically. See Card item layout for the editor workflow, examples, and Configuration API contract.

For an editable Date field on a Form, the item can choose the initial calendar year shown while the value is empty: the current workspace year, a fixed year such as 1950, or a relative year. This is useful for dates such as a birth date without forcing users through decades of month navigation. It is a display preference, not a default value: opening the calendar does not fill the field, mark the form as changed, or save a date. A stored date, keyboard input, and configured minimum, maximum, or allowed-date rules remain authoritative.

The host screens (entity list, details, drawer) are always available and are configured on Runtime screens; create table, card, and form surfaces explicitly when those screens need them.

Table query controls

Section titled “Table query controls”

Table filters and sort options are explicit parts of the surface. They are not derived from visible columns, and a useful business field can be configured for filtering, sorting, both, or neither.

A query target may traverse ordinary references. If an Aid record stores Community, one table can contain the distinct targets Community, Community / District, and Community / District / Region. The full path is the identity, so sharing the same first reference is allowed.

The filter target and the selected-value presentation are separate:

  • the target path tells the server which terminal field to query;
  • the reference breadcrumb path tells a lookup how to display the selected terminal record.

The terminal field controls the input. A terminal Region reference uses the normal Region list, picker, or lookup and filters by Region record ID. Runtime permissions are checked across the complete path.

Where to go next

Section titled “Where to go next”