Source UI layouts#

Source UI layout blocks describe how source fields should be arranged without moving business policy into the UI layer. In BL source, they appear as the value of ui: members on tables or classes; bare group, row, and field-operation examples are source-ui fragments, not top-level declarations.

Layout block#

A source UI layout block contains one or more group declarations.

ui: {
  group main {
    title: "Main";
  }
}

Group names can be identifiers or string literals.

{
  group main {
  }

  group "Posting policy" {
  }
}

Group properties#

Groups can contain key-value properties. Values are expressions.

group main {
  title: "Main";
  columns: 2;
  collapsible: false;
}

Use group properties for presentation metadata only. Approval routes, thresholds, status transitions, and other configurable business behavior belong in tables and resolver functions.

Rows#

Rows group fields into a layout row.

group main {
  row {
    field company_code;
    field document_type;
  }

  row {
    field valid_from;
    field valid_to;
  }
}

Row blocks contain field layout entries.

Row operations#

Row operations let a layout adjust or extend rows by name.

group main {
  append row {
    field approval_limit;
  }

  insert row after field document_type {
    field requires_approval;
  }
}

The anchored row operation shape is operation row anchor field name { ... }, for example insert row after field document_type { ... }. The grammar requires the leading operation identifier before row; after and before are parsed as anchor identifiers, not as standalone row after ... forms.

Field operations#

Field operations apply an operation to a field and can reference another field.

group main {
  readonly field company_code;
  hide field approval_limit with field requires_approval;
}

The grammar accepts the operation identifier, field, the target field, and optional with field OtherField.

Table UI member#

Tables can use source UI blocks directly.

table PostingPolicy {
  field company_code: CompanyCode key;
  field document_type: DocumentType key;
  field valid_from: date key;
  field active: bool required default(true);
  field requires_approval: bool required default(false);
  field approval_limit: decimal optional min(0);

  ui: {
    group "Policy" {
      columns: 2;

      row {
        field company_code;
        field document_type;
      }

      row {
        field valid_from;
        field active;
      }

      hide field approval_limit with field requires_approval;
    }
  }
}

Use ui: for layout and visibility composition. Do not use it as the source of truth for required fields or configurable policy.

Operation reference#

Policy boundary#

UI layout can express how a policy field appears. It should not decide what the policy is.

table PostingPolicy {
  field approval_limit: decimal optional min(0);
  field requires_approval: bool required default(false);

  ui: {
    group "Policy" {
      hide field approval_limit with field requires_approval;
    }
  }
}

This is layout behavior. The command that posts an invoice still has to resolve PostingPolicy, enforce missing configuration failures, and raise declared message-backed errors when a policy blocks the operation.