Using the JSDO dialect of the Kendo UI DataSource : Sample Kendo UI DataSource instantiations using the JSDO dialect : Sample instantiation for a Rollbase Data Object Service
  

Sample instantiation for a Rollbase Data Object Service

The following DataSource is instantiated to access a Rollbase object resource, Customers:
Table 4. Sample for a Rollbase Data Object Service
myjsdo = new progress.data.JSDO({ name: 'Customers' });

var dataSource = new kendo.data.DataSource( {
type: "jsdo",
serverPaging: true,
serverFiltering: true,
filter: { field: "State", operator: "eq", value: "MA" },
serverSorting: true,
sort: { field: "State", dir: "desc" },
transport: {
jsdo: myjsdo,
/* tableRef: "Customers", */
countFnName: "count",
},
error: function(e) {
var dataErrors, error = "", i, j;

console.log('Error: ', e);
if (e.errorThrown) {
error = "\n" + e.errorThrown.message;
}
dataErrors = this.transport.jsdo.ttCustomer.getErrors();
for (var i = 0; i < dataErrors.length; i++) { /* each error */
error += "\n" + JSON.stringify(dataErrors[i]);
}
alert("JSDO error(s) returned: " + error);
e.preventDefault();
}
} );
Note that this example DataSource accesses a JSDO that is instantiated prior to instantiating the DataSource itself. This also assumes that a user login session has been created for the JSDO and a Data Service Catalog describing the Customers resource has already been added to the JSDO session. For more information on creating a user login session for a JSDO and adding a Catalog to the session, see progress.data.JSDOSession class.
Following is a brief description of the configuration options specified in the sample definition for the JSDO dialect of the Kendo UI DataSource shown above:
*Setting the standard type property to "jsdo" — Specifies that the Kendo UI DataSource is being instantiated for the JSDO dialect.
*Setting the standard serverPaging, serverFiltering, or serverSorting properties to true — If server* properties are true, the specified processing (paging, filtering, sorting) is performed on the server, and if server* properties are false, the specified processing is done locally by the Kendo UI DataSource.
For example, if the serverFiltering property is true, the settings for its related filter property on the DataSource (or from any more recent invocation of the filter( ) method on the DataSource) are passed to the resource's Read operation on the server to filter the data before it is returned to the client. If serverFiltering is false, the latest DataSource filter settings are used to filter the data that already populates the DataSource. The same is true of the remaining server* configuration properties and their related property settings, such as the settings of the serverPaging property and its related pageSize property, and the settings of the serverSorting property and its related sort property.
Note: When any server* properties are true, the format of the related property values that the DataSource passes to the resource's Read operation depends on the Data Object Service type (OpenEdge or Rollbase). For more information, see the description of the JSDO fill( ) method.
If all of these server* properties are false, the JSDO receives all the records for the single table of the Rollbase resource, in whatever order they are received from the resource's most recent Read operation on the server, and passes them to the DataSource which then manages all paging, filtering, and sorting of the records in its own internal memory.
Note: The JSDO dialect of the DataSource does not support setting the serverGrouping or serverAggregates configuration properties to true in this release. You should either leave these properties not set, or set them to false. That is, any data grouping and aggregate features of Kendo UI can only be managed by the Kendo UI DataSource itself. If you set any of these properties to true in this release, the respective feature is ignored by both the server and the JSDO dialect of the Kendo UI DataSource.
*Setting the JSDO dialect jsdo transport property — The jsdo property specifies the JSDO that is accessed by the DataSource. In the sample, an existing instance of the JSDO (myjsdo) is specified. You can also specify the name of a JSDO resource as a string, and the DataSource will create its own instance of the JSDO for you. This is the same resource name you would use to create the JSDO yourself. In this sample, you would specify the jsdo value as "Customers".
*Setting the JSDO dialect tableRef transport property — Required only for a JSDO created for a multi-table resource, the tableRef property specifies the name of the JSDO table whose data the DataSource handles. So, for a Rollbase object, which is a single-table resource, you can specify the name of the resource itself (Customers in the sample) or leave it unspecified (or commented out as in the sample). Note that to access other Rollbase object resources provided by the Data Object Service, you need to create a separate Kendo UI DataSource and corresponding JSDO for each Rollbase object, and attach it to a Kendo UI widget appropriately.
*Setting the JSDO dialect countFnName transport property — The countFnName property specifies the name of the server JavaScript method that returns the total number of records in the server result to the Kendo UI DataSource when using server paging (serverPaging == true). Note that for a Rollbase Data Object Service, the name of this method is always "count", as shown in the sample. Although it always takes the same value, you must always specify the value for countFnName, because the DataSource does not know that its JSDO is connected to a Rollbase or an OpenEdge Data Object Service.
*Setting the standard batch property is not supported — Note that Rollbase Data Object Services do not support setting the DataSource batch property to true. (The sample uses the batch property's default value of false.) The Data Object Service Create, Update, and Delete operations process the data only for a single record change in each network request to a Rollbase object resource.
*Handling the parameter (e) and associated JSDO errors returned by the DataSource error event handler function (Updated for Progress Data Objects Version 4.3 or later) — The error event handler function is called when an error occurs while performing CRUD operations on a remote data service (the JSDO, in this case). An error can thus be returned when invoking the read( ) method or the sync( ) method on the DataSource.
As shown in Table 4, the errorThrown property of the event parameter (e) is set, along with some additional properties, depending on the types of errors returned. To process these errors for a JSDO, you can look at the following:
*e.errorThrown.message
*The result of calling getErrors( ) on the JSDO table reference that the DataSource is accessing
If an error occurs when invoking the DataSource sync( ) method when saving changes in the JSDO to the server, the following generic message is typically returned in e.errorThrown.message: "JSDO: Error while saving changes.". This message is returned if one or more errors occurs while saving JSDO changes.
Additional errors from calls to the JSDO dialect read( ) or sync( ) method can be returned using a single call to the JSDO getErrors( ) method on the JSDO table reference. This method can return an array of error objects (dataErrors in the sample), with each object containing properties depending on the type of error:
*errNum — An error number that appears only in errors from operation routines running on the server.
*error — A string containing an error message, depending on the error type (type property value).
*id — The internal ID of any single record object associated with the error. This value can be used to return the record and its current field values by calling the findById( ) method on the JSDO table reference.
*responseText — A string that can contain additional error information for general network and server errors, regardless of the operation.
*type — Identifies the type of error, indicated by a numeric constant.
The sample loops through the dataErrors array to log the contents of each error object as a string using the standard JSON.stringify( ) method. However, for each CRUD operation on a Rollbase object resource, the getErrors( ) method typically returns only a single error object containing a type and error property. In some cases, a responseText property might also be returned with additional information for a network or Rollbase server error. For more information on the possible output from getErrors( ), see the getErrors( ) method description.
So, when the sample error function executes, it:
1. Logs the entire contents of e to the console log.
2. Creates a multi-line error string starting with the contents of e.errorThrown.message.
3. Concatenates one or more error lines to the multi-line error string for each error returned by getErrors( ) (typically only one additional error line for a Rollbase resource error).
4. Displays an alert box showing the contents of the multi-line error string.