Kendo UI Scheduler needs a data source to be bound to and uses a special type of Kendo UI DataSource: kendo.data.SchedulerDataSource. The SchedulerDataSource contains instances of a custom Kendo UI model: kendo.data.SchedulerEvent, which represents the event data items of the Scheduler.

When binding the Scheduler to a local array, you can switch from a "day" to a "week" view, edit the events, create new events, and delete existing ones. However, these changes will not be kept in-memory, which essentially means that they will be lost when the user refreshes the page.

The example below demonstrates how to initialize a Scheduler with two events and how to bind it to an array of JavaScript objects.

Binding a Kendo UI Scheduler widget to a remote service persists its events. This means that users are able to return, update, or delete them.

For more information on Scheduler remote data binding examples based on sample scheduler events, see Kendo UI online demo library. Note that to support cross-domain requests, the remote service uses JSONP.

Important

If your own service lives in the same domain as the website, you do not need to use JSONP—use JSON instead.

When binding to a remote service, it is advisable, while not mandatory, to do the following:

Set the timezone option of the Scheduler. It is used to tell the widget in what timezone its events are created and stored on the server. If the timezone is not set, the Scheduler will use the current timezone. This means that users with different timezone settings will see different start and end times. Setting the timezone of the Scheduler will make the widget display the same start and end times regardless of the current user timezone. For more information on timezones and how Kendo UI Scheduler works with them, see the article about timezones.

Send the Scheduler event date fields (start and end) to the remote service in UTC format. The parameterMap option from the previous example does the same:

Example

17px is a hard-coded value, which should match the scrollbar width. It can be calculated and set with JavaScript before printing if desired.

In addition, the Scheduler needs a fixed pixel width for itself or some of its ancestors. Otherwise, it may resize during printing, which will cause the displayed absolutely positioned events to become misaligned. If the widget is part of a fluid layout, a fixed width can be set only for the printing task and then removed, as demonstrated in the example below.

Kendo UI Scheduler supports adaptive enhancements like changes in styling and behavior in order to remain consistent with the specific user device experience. For instance, when editing on a mobile device, Kendo UI will slide in a new screen for the user, which is a departure from the more desktop-like popup behaviors.

To enable the adaptive rendering feature, set the mobile property to true, "phone" or "tablet".

The Kendo UI adaptive mode requires scripts, which are normally part of the Kendo UI Mobile (Hybrid) library (kendo.mobile.min.js). However, these scripts are also included in kendo.web.min.js and kendo.all.min.js. If you are using individual widget scripts or a custom combined script, make sure the relevant scripts are included.

Each adaptive Scheduler is rendered inside a separate Kendo UI Mobile Pane. Since the panes are absolutely positioned, they can overlap with other content on the page. To avoid this, wrap the Scheduler inside a <div> container that has a position:relative style and a set height. The height must be consistent with the Scheduler's height. Note that the absolute position is required for the transitions between the main and editing views to work correctly.

The example below demonstrates how to configure the adaptive rendering mode of the Scheduler.

Specify the JavaScript function which will handle the event during the initialization of the widget.

Use the bind method of the widget after initialization.

The event handler is the JavaScript function invoked when the event is fired. The argument of the event handler is a JavaScript object which contains event specific data. Get a reference of the widget, which fired the event, via the sender field of the event argument. The function context of the event handler (available via the this keyword) is set to the instance of the widget which fired the event.

The example below demonstrates how to subscribe to a Scheduler event during the initialization of the widget.

Was this article helpful?

/

Give article feedback

Tell us how we can improve this article

Code samples are inaccurate / outdated.
I expected to find other / more information.
There are typos / broken links / broken page elements.
Content is inaccurate / outdated.
Other
By checking this box you consent to Progress contacting you by email about your response on this page.

Frameworks

Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.