I'm working through a project utilizing the Kendo UI Scheduler. I am trying to decide how to best handle the RecurrenceExceptions for recurring events. The recurring events work perfectly fine and I think I have my head wrapped around handling sine exceptions, but what about multiples?
For instance, we have a meeting that happens every Tuesday:
RecurrenceRule is "FREQ=WEEKLY;INTERVAL=2;BYDAY=TU"
If someone wanted to cancel this once, the RecurrenceException would look something like this: "20150519T140000Z;"
* from my understanding, the RecurrenceException tells the scheduler not to show the recurring event on this date/time.
What about multiples times? Do I really have to parse an ever-growing delimited by a semicolon? That doesn't seem very practical in the long run. Yes I get it will be awhile before it becomes a problem, but is there a better way to handle this than splitting a long string in the database?
It would seem to me that the better way would be to reference the original recurrence in a new event and then designate the rule there that would pertain to the first one. It makes more sense to me to have multiple entries that are exceptions to the rule rather than track all the exceptions in one field.
What's a practical way around this?
4 Answers, 1 is accepted
The recurrenceException field is designed to match the iCal EXDATE field defined in the RFC5545 specs. That is why we decided to keep the list of the exception dates as a semi comma separated list. If you would like to use a more optimized way to keep the exception dates, then there is no problem if you still set the recurrenceException field correctly when widget is bound.
Basically, the widget strives to follow the iCal specs and any possible optimizations are up to the developer that implements the server part. That being said, we do not have many options for improvement.
As a side note, we found out that the current recurrenceException format differs than the original EXDATE format. We will address this in the next official release of Kendo UI due the end of next month.
Regards,
Georgi Krustev
Telerik
Rank 1
Hi Georgi,
By "recurrenceException format differs than the original EXDATE format", what are you referring to exactly. It appears to be the same as the spec, or am I missing something? Just so I am aware of the format change when the new update is available.
Also I actually already started down the road of what you suggested regarding storing the dates. I added another table that stores the individual exceptions and have those queried and a custom string built before returning the entry to the Scheduler widget. This prevents the string list from getting really long since the query results are only in the ranges that the view window in the Scheduler currently shows (Day, Week, workWeek, Month, Agenda).
The current exception dates are kept as semi-colon separated string into the recurrenceException field. The specs, however, says that the value needs to be comma separated value. That is why we will need to change the format of the exception dates. Of course, the code will be 100% backward compatible, which means that it will support both formats - semi-colon and comma separated values.
Regards,
Georgi Krustev
Telerik
Rank 1