LoadOnDemand
Feature
Loads the host Calendar's CrudManager on demand as the date range required to produce the UI changes.
Passes the requested startDate and endDate as extra HTTP parameters along with the load request.
By default, the HTTP parameters are called 'startDate' and 'endDate'. This is configurable using the startDateParamName and endDateParamName configs.
The date values are formatted according to the dateFormat config.
Usage:
new Calendar({
features : {
loadOnDemand : true
}
});
Using recurring events
When using this feature when recurring events are in the database, all recurring events which started before the requested start date, and have not yet finished recurring MUST be sent as part of the return packet so that the Calendar is able to populate its UI.
Only the base recurring event definition is stored in the Calendar's EventStore.
When asked to yield a set of events for a certain date range for creating a UI, the EventStore automatically interpolates any occurrences of recurring events into the results. They do not occupy slots in the EventStore for every date in their repetition range (that would be very inefficient, and might be infinite).
Handling data load failures
If a network or server error is detected, the Calendar will fire a loadOnDemandFail event so that an application can produce an error UI and handle the situation.
A handler should return false to prevent the default provided error UI from showing.
If there is no handler, or the handler does not return false, a default error UI is shown using MessageDialog.
Using with showEvents in the sidebar date picker.
If you have configured the Calendar's datePicker to showEvents, the date picker will also initiate a request whenever it navigates forward or backward in time.
This could interfere with the current Calendar mode, so in this case, this feature extends the requested date range to include the date range which encapsulates both widgets' required ranges.
This may mean that a large block of events could be loaded if the date picker is navigated in time a long way while leaving the Calendar's main view date the same.
The alwaysLoadNewRange property must not be set in this use case because both widgets will initiate requests, and this would cause an infinite recursion of event requests.
This feature is disabled by default.
Useful configs
| Config | Description |
|---|---|
| dateFormat | Date format for the HTTP parameters |
| startDateParamName | HTTP parameter name for the start date |
| endDateParamName | HTTP parameter name for the end date |
| beforeRequest | Hook to mutate the load request options |
| alwaysLoadNewRange | Force a load on every new date range request |
See also
- Calendar — The Calendar that this feature loads data for
- CrudManager — The CrudManager used for server communication
Configs
Configs are options you supply in a configuration object when creating an instance of this class-
The DateHelper format string to use to encode the start date and end date of the events to load when the view requires a new date range.
-
The name of the HTTP parameter which contains the end date of the view requiring new data.
-
The name of the HTTP parameter which contains the start date of the view requiring new data.
Properties
Properties are getters/setters or publicly accessible variables on this class-
Identifies an object as an instance of LoadOnDemand class, or subclass thereof.
-
Identifies an object as an instance of LoadOnDemand class, or subclass thereof.