Mar 7

Written by: Rodney Joyce
3/7/2007

This is extracted from this pinned post - please post on the Forum here and not on these comments.

I want to implement Recurring Events in the ST Events module, but there are a number of architectural design decisions to make.

The biggest one is how the records are stored in the database. For example, I think there are 2 possible ways of doing this:

1) Have a flag or settings against a single event record that marks it as a "Recurring Event". When the display renders the record it populates each date with the event as if it were on that date, but in reality there is only one record.

2) When you are editing, you specify how far to go ahead in the future and on save an event will actually be made for each instance within this period.

There are pros and cons for each method.

Method 1)  Less database work and storage. Each instance is not actually an instance and I am not sure you would be able to have RSVPs against each event or modify a particular event. If you change the master they all change. This makes it easy if you want to delete or edit it though.

Method 2) Can't go to infinity like method 1, but as each record is persisted in the database you can then treat them as completely normal (e.g. PP and RSVPs) as if they were created manually X months into the future. This is more of a quick way of creating events x months ahead - you can then edit each event. The downside is that you can't make changes to the master and ripple them down. You'd have to change each one (unless a lot of time was spent on the Edit function.  The Smart-Thinker architecture may actually make this method much easier to implement, but would it meet people's requirements?

I came across a blog post on the Ventrian site which talks about this a bit more... very interesting.

Please give your views on this - how do you see Recurring Events working on your site, and if you are technical please give your views on the methods (are there any more?)

Tags: