Posted By zoulou on 1/23/2006 1:11 AM

From practical experience, recurring events should not be implemented any differently than normal events. I would just permit some easy way to insert multiple events at create time, for exemple ' every week ; next 3' would create 4 events with only a difference in the eventdate. Once you've inserted the multiple recurring events, each of them should be an independant event

It should NOT be 1 event with some specific property of beeing 'recurrent'

I disagree. From practical experience, I would recommend that you handle recurring events with a single event that has a 'recurring' property. Of course, there are a few other details to go along with the 'recurring' property but spending the extra time to do it this way will help you avoid a lot of the other problems with the other solutions to handling recurring events. For instance, what if someone wants to test your site out and drops 5 events that recur every day with no end date? We've had that happen. It would not have been pretty if we had inserted a row for each occurence. OK, so limit them to 50 occurences or end date it to stop after a year. Then you're stuck with a burdening the user to remember to extend the event after a year is up. And don't forget about updating events. Sure would be a pain to update each occurence to an event if you messed it up when you entered it.

Obviously I don't want to come right out and tell you how to design it to correctly handle recurring events, but I will just mention that there are solutions out there that solve the recurring event problem from a pattern perspective.

I hope that my input helps a little in your quest to build and integrate your own calendar. I was really sweating recurring events before I ran across the best way to solve it. Now before anyone runs over and tries our site out and comes back here and posts "Why should we listen to you? Seeing as how you don't support recurring event exceptions!" All I can say is: we're almost there. It's been on my list of things to do for a long time now. From a technical perspective, the actual solution is yet again pretty trivial. The hardest part in general is making sure that your UI supports the changes that you are implying you will be making. And we also have some complexiities tied to our event update process that needs to be incorporated.

We've still got a lot of work in front of us, but we are excited to finally have the door open just a little.

Regards,
Matt

Posted By mattsmith321 on 1/25/2006 4:54 PM
Of course, I couldn't even leave a comment here without screwing up the quotes, so you might not want to listen to anything I have to say!

Posted By zoulou on 1/27/2006 1:08 PM

What a surprise to find a link to a new 3.2 version of avcalendar on www.dotnetnuke.com ! (event forum or directly here http://www.avanced.net/Downloads/tabid/30/Default.aspx    Alas ! ,  at the first event created I get the infamous :

DotNetNuke.Services.Exceptions.ModuleLoadException: The conversion of a char data type to a datetime data type resulted in an out-of-range datetime value. The statement has been terminated.

OK, it's a beta. But where is there a not-beta version of avcalendar ?

So if I create a recurring event each wednesday for a team meeting (with no end date), how would you represent this in the database? Or do you make them always put in a end date. What about moving a recurring event, would you have to change each instance?

I had to write a batch job scheduler once in asp.net, and I've been using the same design as I've been updating my own calendar module (which isn't designed for mass-consumption, just for my gaming group on a DNN platform). The way I've approached the problem is to create an additional table in the db schema - cal_eventseries, if you will. And track a 'series_id' for a set of events that are recurring. And then link the events in the cal_events table using that series ID. In the series table, I list the information that was used to create the series - like recurrance type (d, w, m, a, etc) as well as frequency (1, 2, 3, 4, etc) and number of occurances inserted. This allows you to deal with 'related events'. But I agree with other posters here that while you insert them en masse, any modification afterwards has to be done as one-offs - otherwise you drive yourself batty on the test-cases.

The hardest part will end up being the inserting/creation here, but you thankfully should have fairly simple recurrances, not have to deal with the 'every first weds of the first full week of the month' or 'the first saturday after the 15th of the month'...those, get annoying.