Kendo UI Designer Overview : Modules and views : Adding and editing a Blank view
  

Adding and editing a Blank view

The Blank view is a user-defined view that allows you to define both its layout and content by dragging and dropping a variety of components, including:
*Layout components (rows and columns)
*Data management components (e.g., Grid)
*Editor components (e.g., Text Box)
*Chart components (e.g., Bar Charts)
*Scheduling components (e.g., Calendar)
*Navigation components (e.g., Toolbar)
*Media Components (e.g., Images)
*Custom HTML components that you define
The layout is based on the Bootstrap fluid grid system, which manages how you can use row and column components to define it. The content consists of individual UI components, most of which can be bound to data.
To define a view instance you have created, you drag-and-drop these two types of components onto the view design panel: initially, the layout components (rows and columns), then the content components (such as editable grid and field input components), which you can drop into existing layout columns or directly into existing rows (where a column is automatically created for the component). You can combine these layout and content components in various ways to define views with a variety of content presentations.
The Blank view template thus allows you to build a custom view with virtually any arrangement of the supported content components. For example, you can build a view that is a variation on the predefined Data-Grid* views or something completely different, such as a stand-alone form without any associated grid, but with another style of data navigation.
Also, unlike the Data-Grid* views, the Blank view allows you to specify multiple data source instances from one or more data providers to bind data to the view. To complete the data binding, you code view factory event functions in a JavaScript file that is generated for the view with initial AngularJS code, depending on the components and events you have added to the view.
For example, the following running Blank view instance (labeled Customer View) is a form constructed from a toolbar for data navigation and seven content components:
Figure 32. Blank view running in app with toolbar and form
KUIB_Blank_View_Run_HTML.png
The Toolbar component is configured with four buttons for navigating the records of a CustomerDS data source instance. This data source is in turn related to a SalesrepDS data source instance by a custom-coded foreign key look-up on the SalesRep field in both data sources. (Note: You must maintain such relationships in the event function code you write. The built-in foreign key support for Data-Grid* views with forms is not available for the Blank view.)
The Customer: and Sales Rep: labels are hard coded and displayed through Label components. The customer number, 1, is a CustNum field value displayed from the CustomerDS data source using a Disabled Text Box component, which displays data in a read-only mode. Alpha and Omega Services is the name of a customer uniquely identified by this CustNum field value and is a Name field value displayed from the CustomerDS data source using a Text Box component, which allows editing of the displayed value to update it in the data source.
The sales rep code, GPE, is the value displayed from the SalesRep field of the SalesrepDS data source using a Disabled Text Box. Gilles Ehrers is the name of the sales rep uniquely identified by the custom sales rep look-up code and is displayed from the RepName field of the SalesrepDS data source using a Drop Down List component, which allows any other sales rep to be selected from the SalesrepDS data source to update its association with the current CustomerDS record.
If any changes have been made to the customer name or to the sales rep associated with the current CustomerDS record, they can be saved by clicking Save, which is a Button component.
For example, clicking Next in the toolbar a couple of times displays field values from the following CustomerDS and associated SalesrepDS records:
Figure 33. Blank view running in app clicking toolbar item
KUIB_Blank_View_Run_Next_HTML.png
You can change the customer name from Tweeto & Tweeter At Large to Tweeto & Tweeter At Large, LLC) and the associated sales rep from Donna Swindall to Kari Iso-Kauppinen, as shown:
Figure 34. Blank view running in app with change to form fields
KUIB_Blank_View_Run_Change_HTML.png
Then save the new customer name and the SalesRep field values in the CustomerDS data source record by clicking Save, as shown:
Figure 35. Blank view running in app with changes saved
KUIB_Blank_View_Run_Save_HTML.png
In this case, the RepName field does not also need to be saved to the CustomerDS record because it is only displayed from the available SalesrepDS records in order to return the associated SalesRep field value based on the selected RepName field value that the user selects.
To add a Blank view to a user-created module, edit the module, which opens a view design page in the module (see Figure 37 for an example), then click Add View at the top of the VIEWS pane.
This opens an Add View dialog box, similar to this example:
Figure 36. Add View dialog box creating a Blank view
KUIB_Add_Blank_View_HTML.png
In this example, the dialog box has customer_view entered as the value of the view Name, Customer View entered as the value of the view Label, and Blank (the default) selected as the view type. The options for entering these values are the same for all user-created views.
The Rolestab opens an Authorization Roles dialog box that allows you to select the user roles that the app can use to authorize access to this view. To know more about roles, see Using roles to authorize user access.
For more information, see the Add View dialog description in Adding and editing a Data-Grid view.
After specifying the Name, Label, and View Type, click Add View to create the specified view and display its view design page for editing, as shown for the customer_view Blank view in this example:
Figure 37. Blank view design page
KUIB_Edit_Blank_View_HTML.png
The Blank view design page displays the following features, top-to-bottom and left-to-right:
*Header — Similar to the header for the app design page, with the addition of breadcrumbs that track your path in the Designer to the current view design page.
*Toolbar — Provides the following tools:
*Save — Saves any unsaved changes in the current view definition to the UI meta-data.
*Revert — Cancels any unsaved changes and returns the current view definition to its state as of the most recent Save.
*Generate — Invokes the Kendo UI Generator to build the current state of the app ready for preview.
*Preview — Either invokes the Kendo UI Generator to rebuild and preview the latest state of the app, or immediately preview the most recent generated build (if one exists). The preview opens in a tab of your default browser using a webpack-dev-server with live data from the data sources mapped to the app views.
*Publish — Invokes the Kendo UI Generator to build a deployment version of the app either for testing (Debug) or production (Release) in their own respective locations. For more information on app builds, see App generation and deployment.
*KUIB_Device_Selector.png — Selects a device whose view you want to simulate in the view design page and which resembles the view as displayed on the physical device at run time. The displayed icon reflects the selected device from these supported devices: Desktop (default), Laptop, Tablet landscape, or Tablet portrait.
The run-time preview that you open from the Designer using Preview always displays according to the physical device where you are running the Designer.
*VIEWS pane (in panel on the left) — Lists the views in the current module, including the example customer_view view. There is also an Add View button (used to create this view) for creating additional views and a search box for locating a view in a long list of views in the module.
*COMPONENTS pane (in panel on the left) — Lists the supported layout and content components that you can drag-and-drop into a Blank view, including the following component categories:
*Layout — Including Col and Row for adding layout columns and rows, respectively.
*Data Management — Content components that bind to a data source and support both navigation through its records and editing of the fields of selected records, for example, a Grid or List View.
*Editors — Content components that bind to a single field of a selected record based typically on the field's semantic type, and that either support editing of the field (for example, a Text Box) or prevent editing of the field (for example, a Disabled Text Box), or that support no data binding, but provide labels for other content components (for example, a Label). Editors support the largest variety of content components for field values of various types.
*Charts — Content components that bind to and chart data points for a single data source instance based on one or more fields along a value axis and a single field along a category axis (or the equivalent, depending on the chart type). Supported charts include area, bar, donut, line, and pie charts.
*Scheduling — Content components that bind to and provide a graphical representation for scheduling data (for example, a Calendar).
*Navigation — Content components that provide no data binding, but that support fully customizable navigation through data, UI, other functional elements of an app (for example a Toolbar or Button).
*Media — Content components that enable you to add images in BMP, JPG, GIF, and PNG format.
*Custom — Content components that support customizable content (for example, Custom Html, which allows you to enter a single <div> element).
Following is more information on working with layout and content components based on this customer_view example. For more information on the individual properties of all supported Blank view components, see the Blank view topics in Kendo UI Builder by Progress: Using the Kendo UI Designer.
*View design panel (in the middle) — Shows a design simulation of the view, bounded on the left and top with a vertical and horizontal ruler. The Blank view design panel initially contains a single Row component containing two empty Col components (a single layout row with two empty columns).
To further define the view instance, you can drag-and-drop additional rows onto the view design panel, then drag-and-drop columns into each row or directly drag-and-drop content components into a row without columns. If you directly drag-and-drop content components into layout rows, the column for the content component is created automatically.
Once you have at least one empty layout column, you can either drag-and-drop a single content component into it, or you can drag-and-drop one or more layout rows into which you can drag-and-drop their own columns or content components. In this way, you can have layout columns that contain rows, each of which contain their own columns or content components with columns created for them, and each empty column of which can contain either a single content component or its own rows, and so on to any depth within the layout grid. However, the Bootstrap fluid grid system does impose some limitations in how layout columns can be distributed in rows.
An layout column that you add, either directly or as part of adding a content component directly to a row, represents one or more horizontal slots of screen space, whose size depends generally on the device and orientation. After add it, you can specify for each column how many slots of space it represents, and Bootstrap dynamically determines how much space that actually is within a given range, based on the device and the remaining available space in its row. The main limitation with Bootstrap is that the sum total of slots for the columns in a row can take up no more than 12 slots of space in their row. Otherwise, excess columns can be bumped to the next row. Also, note that the actual screen size of slots in a row depends on whether the row is nested within a column of a longer row. Any nested row always has less space available than a row at the top level of a view layout. For more information on setting slot sizes for each column, see the description of the COMPONENT PROPERTIES pane, below.
The components already configured in the example customer_view view design panel include:
*Three layout rows — With two columns in the first row and three columns in each of the next two rows.
*In the first row — A Toolbar configured with four buttons for CustomerDS data source navigation in the first column and a separate Button (with the text Save) in the second column.
*In the second row — A Label with the text Customer: in the first column, a Disabled Text Box in the second column for displaying the read-only value of the CustNum field from the current record in the CustomerDS data source, and a Text Box in the third column for displaying and editing the value of the Name field in the current record of the CustomerDS data source.
*In the third row — A Label with the text Sales Rep: in the first column, a Disabled Text Box in the second column for displaying the read-only value of the SalesRep field from the current record in the CustomerDS data source (custom coded as a foreign key to the SalesrepDS data source), and a Drop Down List in the third column for displaying the RepName field from the corresponding record of the SalesrepDS data source and for selecting a new SalesrepDS record (based on its RepName field value) in order to change the sales rep associated the current CustomerDS record by changing its SalesRep field value to the value in the selected SalesrepDS record.
How the data source and field values are specified using the example content components and how their values and relationships are updated is described later in this topic.
Note: The Blank view design panel also has a single custom HTML top section for coding UI templates for content components that can use them. However, unlike the custom top sections available for predefined views, this custom top section is not available for displaying visible HTML in the layout of the Blank view. For more information on custom HTML sections, see Custom HTML sections in this document.
*The VIEW STYLES pane (in panel on the right) — provides an Edit CSS button that enables you to add and edit CSS styles for the view. Clicking the Edit CSS button opens the view's style.css file in a Monaco editor. The style.cssfile is located in application-folder\app\src\modules\module-folder\view-folder, where application-folder is the path to the folder that contains and is named for your web app, module-folder is the name of the folder defining the module, and view-folder is the name of the folder defining the view.
Note: To apply CSS classes (defined in the style.css file) to the view, you must specify the class names in the CSS Class List property in the VIEW PROPERTIES pane.
*CSS Class List: The CSS classes that need to be applied to the view. The classes must be defined in the view's style.css file, which can be opened and edited by clicking the Edit CSS button in the View Styles pane on top.
*VIEW PROPERTIES pane (in panel on the right) — Contains the properties that you can set for a Blank view instance, regardless of the components it contains. These properties specify the data sources for binding data to the view and are available through View's Data Sources by clicking Edit, which displays a dialog box similar to what might be shown for the customer_view example, as follows:
Figure 38. Adding and editing Blank view data sources
KUIB_Edit_Blank_View_Data_Sources_HTML.png
The specified data sources represent instances of data sources you have already defined in data providers that you have created on the app design page (see Data providers and data sources). (In OpenEdge, a data source instance is analogous to an ABL temp-table.) In this example, two data source instances have been added for the view, CustomerDS and SalesrepDS, which names are specified using the Name property. As noted, you select the data source definition for each instance using the Data Provider and Data Source drop down lists. The Page Size property specifies the number of records that the data source instance maintains in client memory at a time. This value is also used by data management components, such as the Grid, to specify how many records to display in each page of records to which you can navigate using the component (similar to the Page Size property for the predefined Data-Grid* views).
In addition, each data source instance you specify is automatically created with a data model that represents the current record of the data source table. (In OpenEdge, a data model is analogous to a buffer of an ABL temp-table.) The name of the model is always in the form of DataSourceNameModel, where DataSourceName is the instance name you specify in the View's Data Sources dialog box. For example, the CustomerDS data source instance has a data model named CustomerDSModel.
You can bind any data that you specify for a Blank view to each content component in the view, not to the view itself. Depending on the component, you can then bind the component to any one of the specified data source instances or to a specific field in the current record specified by its data model. For some components, you bind both a data source and its model, and for others, you bind only a data model.
Note that you must implement appropriate event functions to move data between a data source instance and its data model as described later in this section.
Note: You can also use properties in the Edit View dialog box to change the default names of event handler functions for general events that apply to all views. You can access this dialog by clicking the KUIB_Gear_Control.png drop-down menu for each view (as shown for the example customer_view view listed in the VIEWS pane), then clicking the Edit option. Note also that the default behavior for general event functions has no functional effect. You must add custom code to each event handler function in order to implement any useful behavior for it. Typically, you do not need to change the default names of the general event handler functions. However, the view properties exist to allow this name change if you have the need (for example, to avoid a naming conflict with existing JavaScript code you are using elsewhere in the app). For more information on coding general event handler functions (and changing their names in the source), see General view events in this document. An example of custom coding for the general onShow event function appears in the sample Table 4, which is described later in this section.
Caution: You must ensure that any change to the default name of a general event handler function that you make using its view property you also make to the name of the actual JavaScript function in source code.
*COMPONENT PROPERTIES pane (in panel on the right) — Contains all the properties that you can set for the single layout or content component you currently have selected in the view design panel. (Property settings are available only for components you have added to the view.) In the customer_view view, for example (see Figure 37), the first Col component is selected in the first row, with its two groups of properties shown as follows:
*Screen widths — Properties that you can set to specify the number of slots of horizontal screen space for a given device and orientation. A setting for the Tablet Landscape property is required, because this value is used by default for any other device and orientation properties you do not set for the column. Note also that for reliable layout management, the total number of slots set for all columns in the same row cannot exceed 12. For more information, see the description of the view design panel, above.
*Hide on — Check-box properties that you can select to hide the column on a given device and orientation.
This section provides more information below on setting properties for content components based on this customer_view example. For information on setting the properties of all supported Blank view components, see the Blank view topics in Kendo UI Builder by Progress: Using the Kendo UI Designer.
This is the customer_view view design panel showing the Toolbar selected with its property settings displayed:
Figure 39. Editing Blank view navigation using a toolbar
KUIB_Edit_Blank_View_Toolbar_HTML.png
These settings include:
*Id — The value toolbar0, which you can use to reference the Toolbar instance in event function code. (The Designer provides a default value to uniquely identify every content component in a view.)
*Toolbar Items — A dialog box that appears when Edit is clicked containing properties to define the toolbar navigation items displayed to the user, as shown:
Figure 40. Adding and editing Blank view toolbar items
KUIB_Edit_Blank_View_Toolbar_Items_HTML.png
This dialog box allows you to define various combinations of toolbar Items, with +-icons listed left-to-right, respectively, for adding a:
*Button, similar to the example items
*Split button
*Button group
*Button you can add to any split button or button group you have defined by selecting an existing split button or button group, then clicking the +-icon for adding the button
*Button based on a template
*Separator to organize the toolbar items you are adding
The settings for this Toolbar instance include the icons and properties to add or edit the four button items, which are displayed with the label text First, Prev, Next, and Last. You can delete an existing item by clicking its trash icon, as shown for these buttons, and you can change the order of added items by dragging-and-dropping them in the Items list. You can use the Properties that appear for each selected item to complete its definition, then click Save to save the latest definitions. The Properties for each item, therefore, depend on the type of item that it is. For example, the selected First item (like the others for this example) is a button, has its Id set to access it in code to btnFirst and its Text property set to First.
Other properties that are not set in this example include Primary, which specifies an item to be highlighted, Togglable, which activates the behavior defined by any specified Toggle Event Function for the selected item, and also the option to specify a Click Event Function for the selected item independent of the toolbar instance itself.
*Resizable — Selected in the example, this allows the toolbar to move items into a drop-down list if resizing its container hides some of its items.
*Events — Including:
*Click Event Function — Set to onClickToolbar, a JavaScript function that you define to execute when the user clicks a toolbar item. This function is where you can reference the ID values you have set for this component to implement its behavior. A sample implementation for this event function appears later in this section.
*Toggle Event Function — A JavaScript function that you define to execute when the user clicks togglable toolbar item.
If you select the Togglable check-box for any Toolbar item, you need to set the Toggle Event Function to implement the toggle behavior. Note also that none of the navigation components, such as the Toolbar, have a data binding. Instead, you use an appropriate event function to implement navigation through existing data sources and displayed UI elements.
This is the customer_view view design panel showing the selected Text Box with its property settings displayed:
Figure 41. Editing Blank view data binding for a component using a model
KUIB_Edit_Blank_View_TextBox_HTML.png
These settings include:
*Id — The value textbox0, which you can use to reference the Text Box instance in event function code. (The Designer provides a default value to uniquely identify every content component in a view.)
*Title Text — The value Name, which is optional text that appears when the user hovers over the component.
*Debounce — (Default value: 0) The delay, in milliseconds, between user input and execution of the Change Event Function.
*Model — Defines the data binding for the Text Box, which includes selection of the data model name for the current Customer record (CustomerDSModel in this example) and the name of the field in the model (Name in this example) whose value you want to display and edit in the Text Box.
*Change Event Function — No setting in this example, a JavaScript function that you can define to execute when the user changes the value in the Text Box. This function is one place where you can reference the Id you have set for this component to implement its behavior. However, in this customer_view example, handling the change in value for this component is entirely implemented using the event function set for the Click Event Function property (onSaveClick) of the Save Button component (Id: button0). A sample implementation for this event function appears later in this section.
This is the customer_view view design panel showing the selected Drop Down List with its property settings displayed:
Figure 42. Editing Blank view data binding for a component using a data source and model
KUIB_Edit_Blank_View_DropDownList_HTML.png
These settings include:
*Id — The value dropdownlist0, which you can use to reference the Drop Down List instance in event function code. (The Designer provides a default value to uniquely identify every content component in a view.)
*Data Source Name — The value SalesrepDS, which is the data source selected from the view's data sources to set the component's data binding.
*Data Text Field — The value RepName, which is the name of the field selected from the specified data source both to display in the Drop Down List that corresponds to the current Customer record and to select in the Drop Down List in order to set a new value in the current Customer record.
*Data Value Field — The value SalesRep, which is the name of the field selected from the specified data source to use as the unique foreign key in the current Customer record to identify the SalesrepDS data source record from which to display the current Data Text Field value and to select and set a new current Data Text Field value from the available SalesrepDS data source records.
*Cascade from: The ID of another drop down list in the Blank view. You use this property when you want to build cascading drop down lists in the view. For example, one drop down list may display a list of product categories. When a user makes a selection, the selected category is cascaded to another drop down list, which then displays a list of products for that category. Click here to see an example of cascading drop down lists.
Note: To build cascading drop down lists, you must ensure that the data sources of the drop down lists are related. Kendo UI Builder extracts this relationship from the JSDO catalog of the data provider.
*Cascade from field: A field in the data source of the drop down list from which a selection is cascaded to the current drop down list.
*Value Primitive: Restricts the model to one field of the record.
*Default Item: The item initially displayed in the drop down list. The user can then change the selected item as needed.
*Title Text — The value Salesrep, which is optional text that appears when the user hovers over the component.
*Model — Selects the name of the data model (SalesrepDSModel in this example) used to display the current record from the SalesrepDS data source or to select a new current record from the key value specified by Data Value Field that corresponds to the value the user selects in the list specified by Data Text Field.
*Change Event Function — Set to onChange, a JavaScript function that you can define to execute when the user changes the value selected for the Drop Down List. This function is one place where you can reference the Id you have set for this component to implement its behavior. A sample implementation for this event function appears later in this section.
This is an implementation of the controller.public.js file where you can code the event functions for this view, with property settings from the customer_view example shown in bold:
Table 4. controller.public.js file for customer_view
import BaseController from './controller.js'

class Module1CustomerViewCtrl extends BaseController {
constructor($scope, $injector, stateData) {
super($scope, $injector);
}

// Fired when custom html section is loaded
includeContentLoaded() {

}

// Fired when custom html section loading failed
includeContentError(e) {

}

// Fired when view content is loaded
onShow($scope) {
var that = this;
this.customerDS = $scope.vm.$ds.CustomerDS;
this.salesrepDS = $scope.vm.$ds.SalesrepDS;
this.customerModel = $scope.vm.$viewModels.CustomerDSModel;
this.salesrepModel = $scope.vm.$viewModels.SalesrepDSModel;

this.customerIdx = 0;

this.customerDS.read().done(function(){
var data = that.customerDS.data();

that.displayCustomer(0);
$scope.$apply();

});
}

displayCustomer(operation){
var data = this.customerDS.data();
switch(operation) {
case 0:
this.customerIdx = 0;
break;
case -1:
if (this.customerIdx) {
this.customerIdx -= 1;
}
else {
this.customerIdx = 0;
}
break;
case 1:
if (this.customerIdx === (data.length - 1)) {
this.customerIdx = data.length - 1;
}
else {
this.customerIdx += 1;
}
break;
default:
this.customerIdx = data.length - 1;
}

this.customerModel.id = data[this.customerIdx].id;
this.customerModel.CustNum = data[this.customerIdx].CustNum;
this.customerModel.Name = data[this.customerIdx].Name;
this.customerModel.SalesRep = data[this.customerIdx].SalesRep;

this.displaySalesrep();

}

onClickToolbar(e){
switch(e.id) {
case "btnFirst":
this.displayCustomer(0);
break;
case "btnPrev":
this.displayCustomer(-1);
break;
case "btnNext":
this.displayCustomer(1);
break;
case "btnLast":
this.displayCustomer();
break;
}

}

displaySalesrep(e){
if (this.customerModel.SalesRep) {
this.salesrepDS.filter({
field: "SalesRep",
operator: "equals",
value: this.customerModel.SalesRep });
var view = this.salesrepDS.view();

if (view.length) {
this.salesrepModel.SalesRep = view[0].SalesRep;
this.salesrepModel.RepName = view[0].RepName;
}
else {
this.salesrepModel.SalesRep = "";
this.salesrepModel.RepName = "";
}
this.salesrepDS.filter({});
if (this.salesrepModel.RepName) {
angular.element("#dropdownlist0"
).data("kendoDropDownList"
).search(this.salesrepModel.RepName);
}
} else {
angular.element("#dropdownlist0").data("kendoDropDownList").value("");
}

}

onChange(e){
this.customerModel.SalesRep = angular.element("#dropdownlist0"
).data("kendoDropDownList").dataItem().SalesRep;
}

onSaveClick(e){
var dataItem = this.customerDS.get(this.customerModel.id);
var that = this;

dataItem.set("Name", this.customerModel.Name);
dataItem.set("SalesRep", this.customerModel.SalesRep);

this.customerDS.sync().fail(function(){
that.customerDS.cancelChanges();
});
}
}

Module1CustomerViewCtrl.$inject = ['$scope', '$injector', 'stateData'];

export default Module1CustomerViewCtrl
For more information on controller.public.js files and where to find the file that is generated for a given view, see the topics on coding view event functions in Extension Points and Source Code Customization.
The Kendo UI Builder also supports a dsService API that is inherited by but not used in the sample controller.public.js file for the CustomerView example.
In a Blank view, as described previously, you have data sources and data models. Every data source has a corresponding model property which represents the signature of an item (record) from a data source and its name is DataSourceNameModel, where DataSourceName is the property that references the corresponding data source, for example CustomerDSModel for the CustomerDS data source. These data source and model properties live in $scope.vm.$ds and $scope.vm.$viewModels of the view, respectively. Note that these same properties can also be accessed as array references on this.$ds and this.$viewModels, for example, this.$ds['CustomerDS'] and this.$viewModels['CustomerDSModel'], which are used in the following dsService API examples.
If you set the Model property of a data bound component, that model represents the selected (current) item in the data source. Having that, you can add input (editor) components bound to the same model and update the data source item (because the model is actually an item from its corresponding data source).
At some point you might want to update the changes you have made in the data source. You can achieve this by using the dsService API that is injected into every controller.js file in the generated application and inherited by its corresponding controller.public.js file. The controller.public.js file is the place where you add your event functions. For example, you might have five Button components that have the following five corresponding click event functions that each call an appropriate dsService function: removeClick, cancelClick, saveClick, createClick, and createModelClick. You can then update the changes in the data source by adding these event functions to the controller.public.js file of your view and setting the Click Event Function property of each Button to the name of the corresponding function.
This is a description of the available dsService functions your event functions can call:
Table 5. dsService API
// Returns a new pristine model. Use this function to set your model when
// you want to insert a new item.
createPristineModel: function(dataSource) {
},

// Adds the model to the dataSource and returns the model.
// By default, this operation updates only the local dataSource and
// does not sync with the server.
// If you want to immediately sync the dataSource, you need to pass
// this options value: var options = { sync: true};
create: function(dataSource, model, options) {
},

// Removes the model from the dataSource and returns a pristine model.
// By default, this operation removes the item only from the local dataSource
// and does not sync with the server.
// If you want to immediately sync the dataSource, you need to pass
// this options value: var options = { sync: true};
remove: function(dataSource, model, options) {
return new dataSource.reader.model();
},

// Syncs the local dataSource to the server.
save: function(dataSource) {
dataSource.sync();
},

// Cancels all local dataSource changes, resets the dataSource to the server one,
// and returns a pristine model.
cancel: function (dataSource, model) {
}
This API resides in the app/src/scripts/services/data-source-factory.js file under each web app project folder. (Note also that the extractErrorMessage(e) function also included in this file is a utility function for the Kendo UI Builder and is not supported as part of this dsService API.) You can reference each of these API functions using this.$dsService, which is set in and inherited from the view's base controller.js file as follows: this.$dsService = $injector.get('dsService');
Following are the five example click event functions implemented to call the corresponding dsService functions:
Table 6. dsService API examples
removeClick: function () {
this.$dsService.remove(this.$ds['CustomerDS'],
this.$viewModels['CustomerDSModel']);
},

cancelClick: function () {
this.$viewModels['CustomerDSModel']
= this.$dsService.cancel(this.$ds['CustomerDS'],
this.$viewModels['CustomerDSModel']);
},

saveClick: function () {
this.$dsService.save(this.$ds['CustomerDS']);
},

createClick: function () {
this.$viewModels['CustomerDSModel']
= this.$dsService.create(this.$ds['CustomerDS'],
this.$viewModels['CustomerDSModel']);
},

createModelClick: function () {
this.$viewModels['CustomerDSModel']
= this.$dsService.createPristineModel(this.$ds['CustomerDS']);
}
These examples do not sync with the server, except for the call to this.$dsService.save() to explicitly sync the local data source with the server.