| Table of Contents |
|---|
...
Once you have placed the scheduler widget inside a page with the scheduler context you can start defining some views.
You must fill in the context StartDate and EndDate here and define at least one view.
...
For now, you can choose one of the default views, or read up on how to define views in depth here. Only a unique view id and a name for the view are required, for now.
...
Adding events & configuring last moved/new attributes
...
Multiple event data sources are supported. This is convenient when you want to use different event entities or if you have vastly different requirements for your various events in the scheduler. For now, let’s just define a single event data source.
...
The required attributes are a data source, a resource id, and a start and end date if the event is movable and if it’s resizable.
...
Under UI only the event content is required.
...
In the example above you can see a sample of changed microflow. You can see that the SchedulerContext, as well as the Event objects, are input parameters. The Event is never changed by the scheduler but it can however be used to search for the event in the database like so:
| Code Block |
|---|
[id = $Event] |
Alternatively, the EventId on the context object can be used (if you supplied an attribute for this (if not it will default to the GUID of the object))
| Code Block |
|---|
[EventId = $SchedulerContext/EventId] |
This example simply sets the updated values of the SchedulerContext object on the Event object and commits the changes.
License
To try out the scheduler locally on your pc or even in a Mendix sandbox environment doesn’t require a license. However, a production build will.
...