Home Unanswered Active Tags New Question

Delayed loading

Is it feasible to modify Daypilot to allow the delayed loading of schedule events that are not visible in the current viewport of the scheduler? I wish to display a schedule for a whole year but only load the schedule events into the client if they scroll vertically and horizontally, a la ajax.

Could the loading of schedule events be performed in background thread to allow the user to start interacting with the control without all schedule elements to be loaded, obviously the first batch would be those required for the current viewport.

I appreciate that I am not fully aware of the deign issues relating to this request, so I would appreciate it if you could outline the design issues.

Best Regards

Andrew

Asked by Anonymous 4 years ago.
asp.net
Replies
This feature was originally scheduled for 4.2 release (I already have a proof-of-concept prototype) but I had to move it to 4.4 release.
Comment posted by Dan Letecky 4 years ago.

I have made a couple of post today and they all seem to be answered in v4.4. Look forward to it. Your release and version control can only be commended and I wish a few other companies would adopt the same quality systems.
Best Regards
Andrew

Comment posted by Anonymous 4 years ago.

Hi

A couple of thoughts on the delayed load.

Could this be implemented to allow delayed loading of both the timeline and resources schedule events? I have an application that could list 50 100 resources and for 2/3 weeks this couldbea good amount of events.

Also could the loading be performed in the background? For example, a certain amount of schedule data is required for the current viewport, i.e. Resources A-F and 14 days to get the user started and then the remaining events while the user is scratching his head. The client could keep requesting schedule information from the server, either in a background thread, if feasible, or on a user event, i.e. scroll.

If done in the background a call back interval could be specified by the last server request and specified by a return value in the call back packet i.e. 0 second (no further call backs required as all data uploaded), 1 second (more date is required) or 60 seconds or periodic check for updated data

The call back request could provide the current displayed timeline period and resource lines visible as parameters. On the server a user routine could decide the schedule information to be returned. The user routine would need to have access to or maintain a record of the information uploaded to the client to ensure it provides the next required batch.

If this could be performed in a background thread on the client it could perform live updates to the schedule data which would be a very powerful function for applications were schedule information is very dynamic.

On the same issue do you have any suggestions how a time period could be locked by a user for example if an event is created with a UI dialog? This may be required when looking at the overlap functionality, which I believe should be implemented on 2 levels, on the UI restrict the user from selecting a time period with an overlap and on the server to ensure another user has not already started creating an event for a period. This would need an server event to be fired before a schedule event is created with the time period selected as the parameters.

I hope you understand what I getting at with this functionality. I believe this functionality would provide an improved user experience for last scale and data heavy applications and multi-user environment.

I appreciate that dynamically changing data may not for every application but as a system that would be displayed as a dynamic dashboard it would be invaluable. The only issue I am not familiar threading in Javascript and different browser implementations.

If background load could be implemented it would provide for a better UI experience as it would improve the time to user display and facilitate the live update functionality.

Any help I can provide please ask as I have a large amount of experience of scheduling application in the health industry in the UK and US.

Regards

Andrew

Comment posted by Anonymous 4 years ago.
Andrew, Thanks for an exhaustive description.

What I've considered is the following behavior:
  • Both vertical and horizontal scrollbars are enabled.
  • Only the current viewport is loaded from the server (this includes the background cells - they can't be always calculated on the client before BeforeCellRender has to be taken into account - and the events).
  • When you scroll in any direction, it starts loading the data from the server. Advance background loading is a nice idea but it would come in the next step.
  • The resources list is loaded in advance (in order to determine the scroll range).
This will have many advantages:
  • It will allow to show many more resources (the missing vertical scrollbar is a big limitation now).
  • It will allow to show almost unlimited time range (it really doesn't matter how many events you have since you are only loading a fraction of the total number).
There is only one big issue at the moment and that's the dynamic row height. The current behavior is that the row height is calculated as EventHeight * MaximumConcurrentEventNumberForThisRow.
  • When you load only a part of the row you won't know the right maximum.
  • When you realize that the row height needs to be increased it will need to stretch the row height. This will might be disturbing (especially when it happen while scrolling).
  • One of the solutions would be loading all row at once. This would work but it wouldn't help much for long time range scenarios.
  • I would also like to cache the events and background for the already visited coordinates. This would be also difficult for a row that changes its height during scrolling.
It will require some testing on what's the best performing solution. The scalability has a higher priority than scrolling speed so I will rather give up caching for some cases rather then loading the full row at once.
Comment posted by Dan Letecky 4 years ago.

Is the background load feasible and have you any thoughts on the concurrency issues?

Regards

Andrew

Comment posted by Anonymous 4 years ago.
Yes, I think it's feasible but I would rather add the basic functionality and then experiment with the background loading. The XMLHttpRequest calls are asynchronous so I expect no problems here. It will also have to use some timer to delay the initial loading for a fraction of a second (otherwise it could generate a lot of requests).

I see no big problem there, it's a matter of tuning to achieve the best performing solution.
Comment posted by Dan Letecky 4 years ago.
Cheers
Comment posted by Anonymous 4 years ago.
New Reply
This reply is
Your name (optional):

DayPilot for ASP.NET WebForms, DayPilot for ASP.NET MVC, DayPilot for Java