ResourceScheduler - Initial Draft

[paulo-rico]

Hi all

Further to Scheduler - Resource and/or grouping

Hi @Christine_Chetty,

No, this isn't part of our short term plans. We would gladly accept a pull request implementing that feature though!

this is a draft PR with my effort for implementing the above. It is a draft PR as I know there are at least a few items still to resolve, documentation comments, moving css out of razor files, complete testing, e.t.c., but I wanted to check that what I'm putting forward looks acceptable.

Some notes on implementation

Changes to existing files
The majority of the logic still resides in the Scheduler component. I've tried to do this with minimal change to any existing files.
Reason for changes to existing files are as follows -

SchedulerViewBase.cs
Additional CascadingParameter required in order to attach ResourceScheduler to the View in the same way it does with Scheduler.

RadzenScheduler.razor.cs
Additional signature for SelectView so that an Index can be passed as opposed to an ISchedulerView object. This is because the ResourceScheduler accepts a collection of Views as the ChildContent in the same way as Scheduler does, but each Scheduler component (TResource column) will have it's own Views collection. The actual object wouldn't match, so we select by index instead.

SchedulerSlotEventArgs.cs
Because we are calling from another component, we have to change the scope of the IsDefaultPrevented property to internal.

Navigation methods (OnPrev, OnNext, Today and View selections)
The majority of what the ResourceScheduler does is act as a conduit for the existing Scheduler methods and events, but adding the Resource element to them.

In the case of navigation methods, they all follow the same basic pattern -

        async Task OnPrev()
        {
            var newDate = SelectedView.Prev();

            foreach (var scheduler in Schedulers)
            {
                scheduler.Value.CurrentDate = newDate;
            }
            await InvokeLoadData();
        }

iterating through the Dictionary<TLink, RadzenScheduler<TItem>> Schedulers { get; set; } = new(); that is populated during the render process <RadzenScheduler @ref=@Schedulers[resourceId] and actioning the appropriate existing Scheduler method.

Event Handlers
These are basically extensions of the existing event handlers, but with the TResource added to the args. They are built in the following way using a Dictionary to hold the handler for each Scheduler (example using SlotSelect event)-

        [Parameter]
        public EventCallback<ResourceSchedulerSlotSelectEventArgs<TResource>> SlotSelect { get; set; }


        Dictionary<TLink, Action<SchedulerSlotSelectEventArgs>> OnSlotSelect = [];


        protected override void OnInitialized()
        {
            foreach (var resource in ResourceData)
            {
                TLink id = (TLink)(resource.GetType().GetProperty(ResourceLinkProperty).GetValue(resource));

                OnSlotSelect[id] = async (args) =>
                {
                    var args_resource = new ResourceSchedulerSlotSelectEventArgs<TResource> { Resource = resource, Appointments = args.Appointments, Start = args.Start, End = args.End, IsDefaultPrevented = args.IsDefaultPrevented, View = args.View };

                    await SlotSelect.InvokeAsync(args_resource);
                };
            }
        }

Some of the events have additional code to handle drag drop, in much the same way as the code from the DataGrid to Scheduler drag drop example.

I think that covers most of the bones of the component. I'm sure the source will reveal anything I've missed.

Hope this is of interest

Regards
Paul

[akorchev]

Hi @paulo-rico,

Thank you for the PR.

Here is my honest feedback:

• I couldn't understand what the demo is doing.
• The three generic arguments threw me off. This should not be a requirement and would make it a nightmare to support in Radzen Blazor Studio. You should just need the resource value and the appointment property so you can filter the appointments for the current view.
• The second scheduler interface should probably inherit from IScheduler to avoid the duplication that has been introduced. I would have just extended IScheduler if needed
• I didn't like that you aggregate multiple scheduler instances. I would create a new resource view which repeats Day, Week, MonthView horizontally and gives each view the appointments filtered by resource. This means that we can even use the current RadzenScheduler.

Here is a scheduler resource grouping implementation that I was a part of a long time ago:

https://demos.telerik.com/kendo-ui/scheduler/resources-grouping-horizontal
https://demos.telerik.com/kendo-ui/scheduler/resources-grouping-vertical

The configuration is a lot simpler - a resource is configured via a few properties only and the scheduler does the rest. Grouping was optional - the resources were associated with appointment from the UI via dropdown or multiselect.

If you want to continue working on this PR please check those links.

Here is a quick and dirty idea for the API

<RadzenScheduler Data="@appointments">
     <Resources>
         <RadzenSchedulerResource Name="Room" Property="Room" Data="@(["Room 1", "Room 2"])" />
         <RadzenSchedulerResource Name="Person" Property="User" Data="@(["John", "Jane"])" />
      </Resources>
      <ChildContent>
           <RadzenResourceDayView  />
           <RadzenResourceWeekView />
           <RadzenResourceMonthView />
      </ChildContent>
</RadzenScheduler>

And the Appointment is expected to have a property called Room and User.

[paulo-rico]

Hi @akorchev

Thanks for the detailed response.

I think I'll give it one more shot using these notes. If I'm still miles off the target, I'll give it up as a bad job :)

I'm going to close this PR, delete my fork and start from scratch.

Speak soon.

Paul