Unfortunately, the documentation did not make it in the release, due to a glitch in the software we use. It will be available with the upcoming service pack. Sorry for the introduced inconvenience. We will be glad to answer any questions you may have until then.
Here is an extract of the future documentation:
RadScheduler requires a model of data binding that targets highly customizable information storage and retrieval. For example, the information that defines the events has an obligatory part - a subject, a start time, and an end time entries, and customizable properties like recurrence rule, the recurrence state, and the recurrenceID. It can also include fields for any custom resources and attributes you want to include. If you are including custom resources, there must also be additional data binding to supply the scheduler with the possible values for each custom resource type.
You can bind the scheduler to a DataProvider instance. There are two ways of binding RadScheduler to its data:
• Using the DataSource property. This method lets you bind the scheduler to any object that implements the IListSource or IEnumerable interface. However, when binding the scheduler in this way, you must either make the scheduler read-only, or implement the code to insert, update, and delete appointments using the RadScheduler events. When using the DataSource property, you can't assign multiple resource values to a single appointment.
• Using a Data Provider. This method is the most flexible, but also the most complicated to implement. This is the only method that lets you assign multiple resource values to a single appointment.
Using The Data Source Property
RadScheduler has a DataSource property that lets you bind it to any object that inherits the base abstract SchedulerDataSource class. One such implementation is the SchedulerBindingDataSource. It handles binding to traditional data stores like BOL object lists and databases.
The SchedulerBindingDataSource class has two properties: EventProvider and ResourceProvider that correspond to the provider instances of type EventBindingProvider and ResourceBindingProvider. The EventBindingProvider class is used to handle CRUD operations against an events data store, while ResourceBindingProvider class is used to handle the same against a resources data store. Both provider implementations are nested types to the SchedulerBindingDataSource class and are public. Also the base abstract class for binding providers – the BindingProviderBase<T> is nested as well.
There are also two methods that return base type implementations of the providers:
ISchedulerProvider<IEvent> GetEventProvider() and
An integral and vital part of the providers logic is the Mapping property that requires instance implementing IMappingInfo interface. The IMappingInfo handles the property mappings. Property names from the data store are mapped to corresponding property names of the classes that RadScheduler uses to operate internally. For example a database field name from the table that handles the appointments information is mapped to the corresponding property of a object representing appointment inside the scheduler.
Do not hesitate to write me back if you have more questions.
the Telerik team
Check out Telerik Trainer
, the state of the art learning tool for Telerik products.