Skip to content
EN FR

DataSetManager events

Documentation status: guide — see Maturity and evidence.

The page data cache is reactive. DataSetManager events tell the page when a view data surface opens, refreshes, navigates, edits, posts, cancels, fails, or synchronizes. They describe view-cache state first; they become application or business events only when explicitly escalated.

Event chain

user/component interaction
 -> DataSource / DataSet / DataCursor
 -> DataSetManager event
 -> PageControler / PageModel
 -> component ObjectBehind or page action
 -> optional application action
 -> optional provider/service boundary

Useful event families

Lifecycle: before/after open, before/after refresh, load failure. Navigation: current object/cursor changed. Editing: field changed, before post, after post, cancel, insert/delete where supported. Synchronization: provider sync started/completed/failed.

Validation before post

Use a before-post event as a control point. The handler can inspect the current DataSet, set a mutable allow/cancel result, and provide a diagnostic message. The event is only a hook; reusable business validation should still live in the business action/model when it must apply outside the page.

Refresh after post

After a successful post, refresh dependent DataSets, recompute page status, update action availability, or reposition the cursor. Keep this page-local when it only maintains view coherence. Emit an application/business event only when the post has domain significance.

A small filter DataSet can hold local search criteria while a result DataSet is backed by a provider. Debounce high-frequency input and only refresh/query the provider on a declared search boundary.

Event payload

Prefer explicit context: source/sender, DataSet name, DataSource name, cursor name and mutable control values such as CanPost, message, or stop-propagation flag. Handlers should not infer the active DataSet from unrelated visual state.