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. Authored filter controls and components that share their own criteria publish onto it (Canvas.shareCriteria, consumed per Canvas.useDataContextCriteria; a Slicer is the common example), and their contributions are part of the saved screen.

Selections are shared through the same dataContext but not on this bus: a component publishes its selection itself, and each other component derives what it does with it (see com.smartgwt.client.docs.SelectionSharing). Published selections are interaction state and are never serialized.