Creating an app : Adding and editing views : Blank view : Adding data source instances for a Blank view
  
Adding data source instances for a Blank view
From the View Data Sources dialog, you can review and add one or more data source instances to be used in your Blank view. These instances are defined based on the data sources defined for your app but are scoped to a particular Blank view. To open and use this dialog:
1. Click the Edit button next to View Data Sources property at the top of the VIEW PROPERTIES palette.
2. Click Add Data Item to add a new data source instance from the data sources available for your app, or select an existing data source to review its details.
3. Enter a Name for the data source. This is the name you will select as a Data Source or Model when you want to associate a component with a data source. (The associated model name is the data source name appended with "Model". Models are explained further below.)
4. Select a Data Provider and Data Source. Any provider or source you created for your app from the app design page are selectable here.
5. Choose a Page Size. This number indicates how many records per page from your Data Source will be available to any component you associate with the data source instance. For example, if you bind this instance to a grid (or other data management) component, it displays as many records per page at run time as you specify here. Any other component in the view that is bound to the same data source instance also displays data from that same page of records, unless you add custom code to do otherwise.
6. Click Save when done. Note that you can delete existing data sources by using the trash can icons.
A data source is used with components that work with a set of records. From an OpenEdge ABL point of view, you can think of a data source as a temp-table. When a component works directly with a data source, the binding is two-way, and the JSDO table represented by the data source and the UI data are always in sync. Often, the component can call read/save directly. The following two components are data-bound and use the data source directly:
*Grid
*List View
These components can also be bound, instead, through a model, as described below.
Note: All of the data-bound and model-bound components and their properties are described in Adding content.
A model (or data model) is used to represent the values of a single data source record. The Kendo UI Builder automatically creates a data model for every data source instance created for a view. From an ABL point of view, you can think of a model for a data source instance as a buffer for a temp-table. When a component works with a data model, the binding is two-way, and the UI and the data are always in sync. However, there is NO built-in association between the model and any JSDO table. You, the developer, must manage the movement of values between the model and the JSDO programmatically in an appropriate event function.
This simplifies the case where you create a form, whether or not it is associated with a data-bound component. For example, to create a view with a grid and a form, the grid is bound to the data source and the form fields are “bound” through their data model. When a row is selected in the grid, the framework automatically copies the values from the data source into the data model of the same name, so the currently selected record is shown in the form. When you edit the form fields, the data model is updated; however, these changes are not automatically pushed back to the data source and its JSDO table. You must handle this behavior in an appropriate event function. For more information, see Kendo UI Builder by Progress: Modernizing OpenEdge Applications.
In addition to the Grid and List View, the components that use a data model include most of the editor components (with the exception of the Label). Some of these editor components (list editors) have both a data source and a model:
*Combo Box
*Drop Down List
*Radio Bullet List
The data source represents the list of available values from which to select, and the data model holds the selected item. You can think of a Combo Box, Drop Down List, and Radio Bullet List as a list of rows (data source) combined with a single column (value field) to represent the selected row (data model).
All the remaining editor components are model-bound only. Most of these model-bound components have two fields to specify their Model property, one field to specify the data model itself and a second field to specify the field from that model whose value the editor displays or updates.
In addition, the list components also have the option to specify a single field from their model to represent the value of the component. They all have a Value Primitive checkbox property that when selected provides a two-field Model property similar to other model-bound editor components to select both the data model and its value field.
One other model-bound editor component, Auto Complete, also has a data source as well as a model, but unlike the list editors, this data source is not the data source from which its value is bound. Like other editors without a data source, it relies on a model to bind its value. However, it has a different data source from which options are provided to auto-complete any value the user enters into the component field. The actual value of the Auto Complete itself (the value the user finishes entering) is bound through the model. In addition, Auto Complete has a Value Primitive property to provide an additional Model property field to specify the single field from the data model whose value the component represents.
Note: To use a similar programming model for all the model-bound editors, including the list editors, you might always select the Value Primitive checkbox, if the component has one, to identify a value field. Otherwise, your code must otherwise identify the model field to represent the component value.
Finally, depending on your application, where a component has a data source as well a model to bind its value, you can select a separate data model that is associated with a different data source from the one you specify for the component. For example, similar to Auto Complete, you might specify a model for a separate data source that your code needs to query in order to process whatever value the user enters to update the component data source.