The JSDO dialect of the Kendo UI DataSource supports:

  • The Kendo UI Grid and other Kendo UI widgets in much the same way as other dialects and custom instantiations of the Kendo UI DataSource. However, some standard DataSource property and method behavior is implemented based on a transport that defines a JSDO instance as its remote data service.
  • Access to a single-table JSDO instance or any single table from a multi-table JSDO instance. You use a separate DataSource for each table of a shared multi-table JSDO in order to show master-detail relationships.
  • JSDO dialect transport properties: jsdo, tableRef, and countFnName, which specify, respectively, the JSDO configured for the DataSource, the name of the JSDO table that the DataSource accesses (optional for single-table JSDOs), the name of the JSDO Invoke operation method that the DataSource must call to return the total number of records in the server result set for the JSDO table (required only for server paging).
    Note: You can annotate a Count operation method in a Business Entity that you implement to return the total number of records. With this annotation, you do not need to specify the countFnName transport property for the corresponding Kendo UI DataSource. For more information, see the documentation on coding Business Entities for access by Kendo UI DataSources.
  • Pre-configured DataSource CRUD operations using the individual JSDO CRUD or Submit operations already defined for the JSDO instance—there is no need to configure each DataSource CRUD operation individually.
  • Initial values for Create operations, as defined for the JSDO instance by the resource in the Data Service Catalog for which it is created.
  • The option to configure a DataSource to instantiate its own JSDO for private, single-table access, as well as to share an existing JSDO instance with other DataSources.
  • Access to the JSDO instance directly in DataSource event handlers or Promise deferred functions, for example, to call addRecords( ), the local storage APIs, or invoke methods on the JSDO.
  • The standard sync( ) method on the DataSource, which calls the JSDO saveChanges( ) method, depending on a user's interaction with the connected Kendo UI widget.
  • The standard batch configuration property on the DataSource, which indicates if the JSDO calls saveChanges( ) to invoke a Data Object Service Submit operation (if available in the resource) to send a group of record changes across the network, or to invoke each Data Object Service Create, Update, or Delete operation individually across the network.
  • The standard serverPaging, serverFiltering, and serverSorting configuration properties of the DataSource, which allow a remote data service to manage the paging, filtering, and sorting features (respectively) of Kendo UI. If any or all of these server properties are set to true, the JSDO passes the corresponding property settings for these features to the Data Object Service Read operation to be managed on the server. If any or all of these server properties are set to false (the default), the DataSource manages the corresponding features in its own local memory using the data that has already been returned by the Data Object Service Read operation.
  • The progress.data.JSDOSession class to create a JSDO login session for the DataSource that is validated with either Anonymous, Basic or Form-based authentication over HTTP or HTTPS.
  • Additional JSDO dialect transport properties: autoSave and readLocal, which indicate, respectively, 1) if the DataSource sync( ) method automatically saves pending JSDO data updates to the server or leaves them unsaved in JSDO memory, and 2) if the DataSource read( ) method always reads JSDO data from the server or from the data already loaded into JSDO memory, as follows:
    1. autoSave — When set to true (the default) and the DataSource sync( ) method is called, sync( ) invokes the JSDO saveChanges( ) method, saving all changes pending for the DataSource table (and all other tables) in JSDO memory to the server. When autoSave is set to false and the DataSource sync( ) method is called, sync( ) leaves all changes pending for the tables in JSDO memory without saving them to the server.
    2. readLocal — When set to false (the default) and the DataSource read( ) method is called, the DataSource reads and re-initializes JSDO memory with the specified server data for the DataSource table (and all other resource tables) by calling the JSDO fill( ) method. When readLocal is set to true and the DataSource read( ) method is called, the DataSource reads all data for its table only from the data already initialized in JSDO memory, including any pending changes since the most recent call to fill( ).

    While these properties can be used for a DataSource created for a table without any table relations, these properties are most useful for reading and updating related tables in hierarchical DataSources for the following supported use case: where two related tables (parent and child) reside in the same JSDO instance that you create for an OpenEdge ProDataSet resource, and you create a separate DataSource (parent and child) for each table in that same JSDO instance. You therefore:

    1. Create the JSDO for a single ProDataSet resource with the parent and child tables.
    2. Create the DataSource for each table, setting the jsdo transport property for each DataSource to reference the same JSDO instance that you have created.
    3. Set the tableRef transport property for each DataSource to the name of its corresponding parent or child table.
    4. Specify custom settings for both the autoSave and readLocal properties only in the transport of the child DataSource.

    Thus, the parent DataSource transport uses the default values for autoSave and readLocal, while the child DataSource transport uses your custom settings, with autoSave set to false and readLocal set to true.

    At this point, calling read( ) on the parent DataSource initializes JSDO memory for both the parent and child tables, with the data loaded in the child table limited to records that are related to the data in the parent. Any changes made to the child table remain pending in JSDO memory, even if sync( ) is called on the child DataSource. When sync( ) is called on the parent DataSource, any changes made to both the parent and child tables are then saved to the server.

    For more information on managing hierarchical DataSources for this supported use case using Kendo UI Grid widgets to access the parent and child DataSources, see the sample and white paper located at the following Cloud Data Object project page: https://github.com/CloudDataObject/sample-Hierarchical_PDS_Template.

    Note: The brief example described in Sample instantiation for an OpenEdge Data Object Service of this document assumes that only a single DataSource is created to access the specified JSDO instance and its single table.
  • Additional JSDO dialect transport property: useArrays, which when set to false (the default) tells the DataSource to treat each element of a resource table array field as a separate scalar field, with the name field-ref_integer, where field-ref is the name of the array field and integer is a one (1)-based integer that qualifies the array field name based on the order of its value in the original array. When set to true, the DataSource treats any array field as a standard JavaScript array, which requires additional coding to reference the value of each array element. For more information, see the table reference property (JSDO class) description.
    Note: Array fields are supported only for OpenEdge Data Object resource tables. An array field in OpenEdge can be defined for an ABL temp-table using the EXTENT option. For more information, see the description of the DEFINE TEMP-TABLE statement in OpenEdge Development: ABL Reference.
  • Error handling is supported by an error event callback function that provides access to JSDO error information for any single Data Object Service CRUD or Submit operation on a DataSource that returns an error. To access this error information, you have the option of inspecting the callback object parameter, which provides some error information in the value of its errorThrown property and of its xhr property, depending on the type of error returned.

    You can also call the JSDO getErrors( ) method on the JSDO table reference accessed by the DataSource for details of any error or errors returned from invoking a DataSource operation. Using this method, you have no need to inspect the xhr property of the callback object parameter. The error information returned by this method can include all types of errors from invoking a DataSource operation. The errors actually returned depend on the type and configuration of the Data Object resource that handles the operation on the server and the types of errors returned from a given operation request.