Hello,
I’m interested in your iCalendar component and have a couple of questions:
I have an existing table for Events that is capable of storing single event occurences (standard stuff like Title, StartDate, EndDate, etc.). How would you recommend storing the recurrence information? A number of posts around the web recommend having an EventRecurrences table and a RecurrenceExceptions table to go along with the Events table. I think the assumption is that all of the pattern information would be broken out into pieces, rather than stored in one field. Granted, I haven’t played with the component yet, so it may be obvious.
Second question probably relies on the answer to the first, but I already have an Events object (business class). Can I use the classes you return to then populate my objects, or should they be bound more tightly (inherited, etc.).
Back to the first question about database, in a number of items I’ve read related to iCalendar (the standard), I have seen references to GUIDs for events. Right now, I’ve just got a int in the database, do I need to do more?
Finally, I’ve always assumed that my Events table would hold standard single occurence events and that there would be a flag or data in a relationship to let me know that I’ve got a recurring event. Would I want to change that way of thinking and store the pattern for the event even for single occurences?
So many questions!
Thanks for taking the time to respond.
My advice is that you store the pattern string in iCalendar format in the database.
So if you have a table called Event and it has fields Title, Location etc, you add field called something like Pattern and store the iCalendar string there.
Then you can quickly load the string into a RecurrencePattern object and calculate occurrence dates when needed.
Aspose.iCalendar addresses only the part of the iCalendar standard that deals with recurrence patterns. Aspose.iCalendar is just an engine to create and parse recurrence patterns and calculate occurrence dates for them.
Thanks. I’ll start with that and then bug you later when I have more specific questions.
I am going to be updating an existing application with essentially an Events table as well, but I know that the events will always have a defined start date and end date. What I was planning on doing was adding a column to the Events table which will contain a GUID or some other unique id. When a recurring event is created (not all events are recurring in this app), the entire set of occurrences would be generated and made into full-fledged Events, but a new GUID would be used to tie the series together. I hope this will minimize changes to existing code as far as displaying events is concerned, but still allow for an “Edit Series” functionality… just replace the WHERE EventId = id condition with WHERE EventSequenceId = guid and all occurrences will be updated. It also seems like a good idea to store the iCalendar text for the pattern in the events to be able to redisplay the recurrence pattern in the UI. Editing the pattern would seem to require deleting all existing occurrences and regenerating them. Of course, for an open-ended event, this approach would not work. Any thoughts on other ways to handle this? Thanks.
Yes, you often need to be able to link an occurrence back to the “parent” event. GUID is good for it.
My solution to the open-ended problem is to be practical - define a system-wide or user-wide setting for the “window”, say 1 year (or more if needed) and generate events within that window. If the user navigates the calendar beyond the current window, generate events for the next window. That’s why GenerateOccurrences takes search start and end dates - they define the window for long series or open ended series of occurrences.
Hello-
We are using iCalendar in a web Calendar application. Are solution for recurring appointments is to store the pattern in a single appointment record. We don't store all the occurences seperatly. We have 2 types of appointments recurring and not-recurring. When our users load up there calendar, weather it's a day, week, or month view. We first process non recurring appts then recurring.
We query the database for all recurring appointments for that user. The pattern for each appointment is processed into a DateCollection using the getOccurences method and the start and end dates of the calendar period range. Next we check each date in the calendar period to see if it's in the DateCollection. If it is we load it into the calendar with the start and end times of the appointment.
That's it. It works great. And we don't have to have hundreds of appointments in the database.
Editing the Series:
If somone wants to change or delete an appointment in the series we simply modify the recurring appointment by excluding the date using ExDate. Then we create a new non-recurring appointment and store the orgional appointment id in a field called "SeriesID". This links the new appointment to the series.
If we decide to delete the series the recurring appointment and all appointments with the same SeriesID are deleted.
Anyway thats our solution.
Let me know if you have questions.
Brandon