Our pure JavaScript Scheduler component


Post by kukuma »

Hello everyone,

I recently came across an issue in SchedulerPro's vertical mode regarding the eventLayout function and created a bugticket: https://github.com/bryntum/support/issues/8879

Beside the missing Scheduler reference the layoutFn is currently overwriting the behavior of all events.

new SchedulerPro({ 
    mode: 'vertical', 
    eventLayout : { 
        type: 'stack', // default fallback layout type
        layoutFn(items) { 
            console.log(this.scheduler) // should log the scheduler reference
            if(item.someCondition) {
                item.width = this.scheduler.rowWidth 
                // Information in the  Bryntum documentation on how to recreate the expected behavior of the layout types "stack, mixed, pack, none" with a custom layoutFn would be very helpful.
            } else{
            	// item should be treated as "type: stack"
            }
        } 
    } 
})

The layoutFn function in this example should only affect items with matching conditions, while other items should be displayed using the default behavior of the specified eventLayout type.

The referenced bug ticket 8879 has been added to milestone 5.6.9 and it also mentioned the described behavior of the layoutFn in combination with a default fallback layout type.
Will this described functionality also be incorporated into the upcoming version?

Information in the Bryntum documentation on how to recreate the expected behavior of the layout types "stack, mixed, pack, none" with a custom layoutFn would be also very helpful.

I am looking forward to hearing from the community or the development team.

Best regards,
Malick


Post by kukuma »

There are two functions to calculate the bands and the eventLayout inside the bands:
-applyLayout
-layoutEventsInBands

It seems like these are the functions Scheduler uses to calculate the eventLayout types "stack, mixed, pack, none":

This method should not be used directly, it is called by the Scheduler during the row rendering process


Post by marcio »

Hey kukuma,

Thanks for reaching out and for your suggestions.

So, as you can see in the documentation https://bryntum.com/products/schedulerpro/docs/api/SchedulerPro/eventlayout/ProHorizontalLayout#config-layoutFn you need to

Supply a function to manually layout events. It accepts event layout data and should set top and height for every provided data item (left and width are calculated according to the event start date and duration). The function should return the total row height in pixels.

So, you should set for every provided data item. I created a feature request to discuss if it's doable to add a default callback for layoutFn because that could lead to messy positioning, especially with edge cases.

Best regards,
Márcio


Post by kukuma »

marcio wrote: Tue Mar 26, 2024 8:01 pm

Hey kukuma,

Thanks for reaching out and for your suggestions.

So, as you can see in the documentation https://bryntum.com/products/schedulerpro/docs/api/SchedulerPro/eventlayout/ProHorizontalLayout#config-layoutFn you need to

Supply a function to manually layout events. It accepts event layout data and should set top and height for every provided data item (left and width are calculated according to the event start date and duration). The function should return the total row height in pixels.

So, you should set for every provided data item. I created a feature request to discuss if it's doable to add a default callback for layoutFn because that could lead to messy positioning, especially with edge cases.

Hey Marcio,

Thanks for your fast reply, and thank you for creating a feature request for this topic. Could you please provide a link to the request thread?

Currently, the behavior of the events when a custom layoutFn is set is equivalent to the behavior of "type: none". The events overlap, even when "type: stack" is set.

new SchedulerPro({
    eventLayout : {
        type: "stack",
        // Items appear as as if ' type: "none" ' is set also when type is actually "stack"
        layoutFn(items) {
            return this.scheduler.rowHeight;
        }
    }
})

As I understood, this is what you've created the feature request for: to explore the possibility of having the above example result in the items appearing as a stack.


To create a custom layout using the layoutFn that mimics the behavior of "type: stack" (but with alterations like custom height), we would need to reimplement the calculation of the events' positions and sizes. However, it seems that this is not currently possible, as indicated in the documentation:

  • applyLayout(events, resource)

  • layoutEventsInBands(events)

This method should not be used directly, it is called by the Scheduler during the row rendering process.

Executing these functions with the provided data of the layoutFn results in a crash.

To summarize, what we are seeking is a method to incorporate mixed eventLayout types.

new SchedulerPro({
    eventLayout: {
        layoutFn(items) {
            items.forEach(item => {
                if (item.someCondition) {
                    // This Item should not stack and overlap with other elements
                    // or simplified
                    return { type: "none" }
                } else {
                    // This item should stack with other items. We need to calculate the height and top (for vertical width and left) attributes. We would also need to react on the other elements in this events band
                    // or simplified
                    return { type: "stack" }
                }
            });

        return this.scheduler.rowHeight;
    }
}
});

By now, I do not see any way of implementing this behavior with the current Bryntum features, considering the missing applyLayout, layoutEventsInBands, and scheduler reference in vertical mode. I would highly appreciate any suggestions or ideas for a possible way of implementing this.

I assume this to be another, different kind of feature request than the one you've created previously.

Many regards
Malick


Post by marcio »

Hey kukuma,

Here is the link, sorry, I forgot to add it to the previous post https://github.com/bryntum/support/issues/8893

I agree with you that allowing mixed eventLayout will be the result of this topic, and it's a different topic than the previous one.

Best regards,
Márcio


Post by kukuma »

Hey marcio,

thank you very much for the confirmation!

I agree with you that allowing mixed eventLayout will be the result of this topic, and it's a different topic than the previous one.<

I created another feature request for the second topic: https://github.com/bryntum/support/issues/8901


Post by ghulam.ghous »

Hi kukuma,

Our project manager has added a comment on the ticket please check here: https://github.com/bryntum/support/issues/8901#issuecomment-2022891659.


Post Reply