Interface DataContext

Data Context and Shared Criteria

A Canvas.dataContext binds the data-bound components beneath a Canvas to a set of records from one place. It maps DataSource IDs to specific Records; any DataBoundComponent under the Canvas that has a DataSource but no data of its own populates from the matching entry, binding to the nearest enclosing Canvas that carries one. It is how a screen is handed "the records it is about": give it {Order: anOrderRecord} and the order form, detail viewers and related line-item grids beneath it fill in together, with no per-component fetch. See Canvas.autoPopulateData for the rules - a singular component (a DynamicForm or DetailViewer) shows or edits the record; a list component (a ListGrid) uses non-key fields as criteria, and a primary key against a related DataSource pulls related records as ListGrid.fetchRelatedData() would, such as an order's line items.

A dataContext's DataSources are also exposed to rule context as dataContext.<DataSourceID>, so visibility, validation and dynamic criteria can react to "the current Customer" without a component fetching it; and Canvas.testDataContext supplies sample records when none is set, so a screen can be built and tested in isolation.

A dataContext may also carry a reserved sharedCriteria key: a shared-criteria bus that every subscribing component folds into its fetch, contributed through Canvas.setDataContextCriteria() and carrying the envelope in DataContextCriteriaSettings. Two features publish onto it:

• Filter sharing - authored filter controls and components that share their own criteria (Canvas.shareCriteria, consumed per Canvas.useDataContextCriteria; a Slicer is the common example): "filter"-type contributions, part of the saved screen.
• Selection sharing - a selection in one component narrowing others (com.smartgwt.client.docs.SelectionSharing): "dataSelection"-type contributions, interaction state that is never serialized.