Our pure JavaScript Scheduler component


Post by daansatortec »

Hi,

I am currently working on a prototype application to investigate whether the Bryntum Scheduler matches our UX requirements. One of these requirements is that users should only be able to move (drag) events to different resources, but not be able to change their date&time. This corresponds to locking the horizontal-axis, but allow dragging in the vertical-axis.

So far I have only been able to find the opposite of this requirement using:
constrainDragToResource
This constrains dragging events to the horizontal-axis. Our requirements are exactly the opposite of this. What is the preferred method to constrain dragging to the vertical-axis (locked start & end times)?

Visually the UX designers are pushing for a solution where the dragged event proxy element only moves freely in the vertical direction, so simply using validation is not enough. I sort of have been able to achieve this effect using the following code:
function lockEventTimeWhileDragging(scheduler: Scheduler): void {
    scheduler.features.eventDrag.drag.lockX = true;

    scheduler.addListener({
        beforeEventDropFinalize:
            ({ context }: BeforeEventDropFinalizeEventData) => context.timeDiff = 0
    });
}
This works, but is a bit buggy when you are dragging an event to the edge and scheduler starts scrolling.

I also tried to make use of the scheduler.getDateConstraints function, but without success. I can see the function being called whenever I start dragging an event, but the output of this function seems to be ignored.

Post by mats »

This works, but is a bit buggy when you are dragging an event to the edge and scheduler starts scrolling.
In what way is it buggy? Can you please share a video showing the bug?

To constrain to vertical only drag, easiest way is to do:
getDateConstraints : (resource, eventRecord) => {
        return {
            start : eventRecord.endDate,
            end   : eventRecord.endDate
        };
    },

Post by daansatortec »

I tried exactly that, but that doesn't seem to be working for me. I just found out that this doesn't work when you set the following config for the eventDrag feature.
constrainDragToTimeline: false
We need to use that because we have two parterned schedulers and events can be dragged from one scheduler to another.

Also when I re-enable the constrainDragToTimeline setting I am experiencing buggy behavior at the edges of the scheduler. I'll try to capture a video to demonstrate this.

Post by daansatortec »

get-date-constraints-bug.gif
get-date-constraints-bug.gif (169.38 KiB) Viewed 1878 times
This video illustrates two problems when using the getDateConstraints function:
  • Although the event is visually locked to the start & end date, it will still receive a new start & end date after dropping
  • When dragging an event from the edge of the screen it can be moved freely around
On top of these two problems the getDateConstraints function does not work when constrainDragToTimeline is set to false.

Post by mats »


Post by daansatortec »

Ok, that is good. What about the other two issues?
  • When dragging an event from the edge of the screen it can be moved freely around (last part of the video)
  • The output of the getDateConstraints function is ignored when constrainDragToTimeline is set to false. I can see that the function is being called, but the output is completely ignored (I verified this by wrapping the result in an ES6 proxy to see which properties were being accessed).

Post by saki »

What is your configuration for the first issue?

The second issue is confirmed. I updated the ticket as it might be related.

Post by daansatortec »

What is your configuration for the first issue?
I can reproduce this using the Basic demo (https://www.bryntum.com/examples/scheduler/basic/) by adding the following code to the scheduler config:
getDateConstraints: (resource, eventRecord) => {
    return {
        start: eventRecord.endDate,
        end: eventRecord.endDate
    };
},
Also I can only reproduce it by dragging the event along the same resource.

Post by saki »

Thank you for the information. It will be fixed as a part of that ticket.

Post Reply