Dynamic forms, lists and dashboards

Documentation status: guide — see Maturity and evidence.

Complex user interfaces are assemblies of stable functional components over declared data surfaces and event contracts. Build them from the model outward rather than embedding business semantics into one screen.

Forms

Bind edit fields to a DataSource, use a DataCursor for the current object, validate through before-post hooks and/or business actions, then post explicitly. A form is an object projection, not a substitute for the object’s business contract.

Lists and grids

Bind list/tabular components to a DataSource backed by a collection or query. Cursor changes establish context for detail panels and action panels. Filtering can use a dedicated filter DataSet so temporary UI criteria remain separate from persisted model state.

Selection components

Autocomplete, lookup and selector components consume lookup DataSources. Their functional contract should describe single/multiple/conditional selection, displayed value, identifier and context. Remote lookups should be debounced and hidden behind the page data layer.

Split and tabbed views

Treat split/tabbed structures as functional composition. A master region can own the primary cursor; child regions bind to dependent DataSets or the same cursor. Tab selection is usually local; only explicit intentions should cross into the application model.

Dashboards

A dashboard is an assembly of computed or queryable data surfaces, status components and reactive regions. Keep computed business meaning in the model/provider and map the result to visual state in the page. Do not encode business calculations in widget visibility logic.

Prefer semantic navigation events such as ShowView, OpenObject, MoveNext, or Refresh with explicit target/context parameters. Avoid events named after component ids.