Implementing Scheduler Actions on Open Event Frontend
After the functionality to display scheduled sessions was added to Open Event Frontend, the read-only implementation of the scheduler had been completed. What was remaining now in the scheduler were the write actions, i.e., the sessions’ scheduling which event organizers do by deciding its timings, duration and venue.
First of all, these actions required the editable flag to be true for the fullcalendar plugin. This allowed the sessions displayed to be dragged and dropped. Once this was enabled, the next task was to embed data in each of the unscheduled sessions so that when they get dropped on the fullcalendar space, they get recognized by the calendar, which can place it at the appropriate location. For this functionality, they had to be jQuery UI draggables and contain an “event” data within them. This was accomplished by the following code:
this.$().draggable({ zIndex : 999, revert : true, // will cause the event to go back to its revertDuration : 0 // original position after the drag }); this.$().data('event', { title : this.$().text().replace(/\s\s+/g, ' '), // use the element's text as the event title id : this.$().attr('id'), serverId : this.get('session.id'), stick : true, // maintain when user navigates (see docs on the renderEvent method) color : this.get('session.track.color') });
Here, “this” refers to each unscheduled session. Note that the session color is fetched via the corresponding session track. Once the unscheduled sessions contain enough relevant data and are of the right type (i.e, jQuery UI draggable type), they’re ready to be dropped on the fullcalendar space.
Now, when an unscheduled session is dropped on the fullcalendar space, fullcalendar’s eventReceive callback is triggered after its drop callback. In this callback, the code removes the session data from the unscheduled sessions’ list, so it disappears from there and gets stuck to the fullcalendar space. Then the code in the drop callback makes a PATCH request to Open Event Server with the relevant data, i.e, start and end times as well as microlocation. This updates the corresponding session on the server.
Similarly, another callback is generated when an event is resized, which means when its duration is changed. This again sends a corresponding session PATCH request to the server. Furthermore, the functionality to pop a scheduled event out of the calendar and add it back to the unscheduled sessions’ list is also implemented, just like in Eventyay version 1. For this, a cross button is implemented, which is embedded in each scheduled session. Clicking this pops the session out of the calendar and adds it back to the unscheduled sessions list. Again, a corresponding PATCH request is sent to the server.
After getting the response of such requests, a notification is displayed on the screen, which informs the users whether the action was successful or not. The main PATCH functionality is in a separate function which is called by different callbacks accordingly, so code reusability is increased:
updateSession(start, end, microlocationId, sessionId) { let payload = { data: { attributes: { 'starts-at' : start ? start.toISOString() : null, 'ends-at' : end ? end.toISOString() : null }, relationships: { microlocation: { data: { type : 'microlocation', id : microlocationId } } }, type : 'session', id : sessionId } }; let config = { skipDataTransform: true }; return this.get('loader') .patch(`sessions/${sessionId}`, JSON.stringify(payload), config) .then(() => { this.get('notify').success('Changes have been made successfully'); }) .catch(reason => { this.set('error', reason); this.get('notify').error(`Error: ${reason}`); }); },
This completes the scheduler implementation on Open Event Frontend. Here is how it looks in action:
You must be logged in to post a comment.