Skip to content
EN FR

View data cache

Documentation status: guide — see Maturity and evidence.

A view should bind to a page-level data surface rather than directly to a database, service, provider, or raw business collection. The view data cache provides that stable surface.

The three data surfaces

  • DataSet: what data is visible in this view context? It can represent records, objects, a filtered subset, query results, or a computed projection.
  • DataSource: what stable binding surface does a component consume?
  • DataCursor: what is the current object or current navigation position? It carries context for master-detail and nested views.

Together they form the local data memory of the page.

Data path

functional component
 -> DataSource
 -> DataSet
 -> conceptual Collection
 -> Provider
 -> local memory / persistence / service / stream / remote source

The component should not know which provider supplies the data. This lets the same view work against a local provider, persistent provider, computed provider, paginated service, or remote adapter.

Master-detail

Use a DataCursor to carry the current object from a master view. A dependent DataSet can then resolve a collection or projection relative to that object. Cursor movement is a view-context change; it does not imply that the business object changed.

Local-first remote access

When the provider is remote, keep a local DataSet cache. Tab changes, row movement, temporary filters, panel expansion and similar UI actions should remain local by default. Search, save, validation, synchronization, and process transitions may intentionally cross the provider/runtime boundary.

Declaration rule

DataSet, DataSource and DataCursor are view/cache concepts. Do not apply conceptual-facet field classification such as kind=slot|attribute to them. That classification belongs to model field declarations.