Our pure JavaScript Scheduler component


Post by rrajewski »

I'm trying to upgrade from version 1.2.4 to 2.2.4 and am having some trouble with a behavior change.

Previously in the 'eventdrag' and 'beforeeventdropfinalize' events we changed the event.context startDate and endDate to achieve a snap like effect based on business logic.

When the 'eventStoreUpdate' fired:
- In the old version the event has been updated with the start and end from the context changes.
- In the new version the event start and end are not the what was set in the context, but instead the dates where the event was dropped.

Is this a bug or is there something I should be doing differently?

Post by saki »

The beforeEventDropFinalize event was never meant to serve as a place to manipulate start/end dates of the event but to allow confirmations such as here: https://bryntum.com/examples/scheduler/validation/ (click the Enable Confirmations button in the header to see it in action).

If you only need snapping then you can use snap config option.

Post by rrajewski »

Is there a valid place to change the dates? Should I change them directly instead of using the context?

example logic: if the dragged event dragged to the left and is more than halfway overlapping an event, the the start date becomes the start date of the overlapped event. the overlapped event and all events to the right are then shifted right to make room for the dragged event.

Post by saki »

Actually, we could make event start date in context mutable.

I have created the ticket for it here:
https://app.assembla.com/spaces/bryntum/tickets/9263-context-start-date-should-be-mutable-in-beforeeventdropfinalize-event/details

Post by dimehb »

If you decide to pick this up, couldn't you take this one step further? The onDragDrop function could be improved so the beforeeventdropfinalize event handler can pass some data and extend the continueFn.

We extensively customized the drag and drop behavior. For example, we have a constraint resolution window which renders a modal in case some constraints have been violated. It is possible some of the records in the dragData object have to be rejected. At this moment we would have to modify the me.dragData object (which is used in the finalize method) directly but it seems likely this will break more things than it will solve.

Something like this:
onDragDrop: function(e, id) {
[...]
const {shouldContinue, dragData } = s.fireEvent('beforeeventdropfinalize', me.schedulerView, dragData, e, continueFn, cancelFn);
            if (shouldContinue) {
                continueFn(dragData); // Possibly currying, overrides, ...
            }
        } else {
            cancelFn();
        }    
    }
    

Post Reply