View diagnostics and testing

Documentation status: guide — see Maturity and evidence.

View failures are easiest to diagnose when the model, page data cache, local event layer and rendering layer are tested separately.

Debugging order

1. Verify the model/package/view is loaded.
2. Verify the target ClassItem/ObjectItem and collection exist.
3. Verify DataSet, DataSource and DataCursor names resolve.
4. Verify the current cursor/object context.
5. Verify the functional component is bound to the intended data surface.
6. Verify the PageControler owns the component/frame.
7. Verify ObjectBehind/PageModel event mappings.
8. Verify whether the event is local, parent-routed, application-level, or business/process-level.
9. Only then debug provider, RPC, service, persistence or rendering-specific behavior.

Diagnostics to expose

For a reusable view, log or surface the view name, functional component name, concrete implementation identifier when useful, DataSet/DataSource/Cursor names, event class, source/sender, current object identity, provider state, and escalation target. Missing dependencies should fail visibly rather than silently doing nothing.

Tests

Test view metadata loading, data-surface resolution, master-detail cursor propagation, before-post cancellation, after-post dependent refresh, local event consumption, explicit escalation to actions, child-to-parent and parent-to-child routing, refresh-loop guards, and provider replacement/local-versus-remote behavior.

For web components, also test subscription cleanup, local state separation, debounce/batching, loading/error/offline states and that a purely local event does not produce an unexpected remote call.

Acceptance criterion

A view is correctly factored when the same conceptual model can be projected through another concrete rendering implementation and the same functional component can be backed by another provider without redefining the business semantics.