[geeklog-devel] Calendar Plugin - Recurring Events

[Joe Mucchiello]

At 09:38 AM 4/1/2010, Samuel Leathers wrote:
>Just some thoughts. Wondering what everyone thinks, especially Vlad,
>since he's writing a proposal for this plugin.

Once there was a bounty to fix the calendar plugin and I wrote a lot 
of the fixes requested for the bounty. The patch for Geeklog 1.5.1 or 
1.6.0 (I forget which) is in the download section 
http://www.geeklog.net/filemgmt/index.php?id=933 Feel free to look at 
it and/or steal from it. My personal life interfered with getting 
that beta ship shape and I ended up removing the recurring events 
stuff just to make a release as my life went to hell. The forums also 
have some posts about it.

But I did design it and in the end I felt it required two tables. One 
stored the "event info" and basically looks like the existing table 
with a few extra fields. The recurring data was stored in a text 
field and was basically the vcard recurring info format. The other 
table is an "event instance" table, it too has most of the existing 
fields as well as a parent_id field so you can link it back to the 
original event. When you save a single event, an entry is entered 
into both tables. When you save a recurring event, one entry goes 
into the info table and multiple entries are placed into the instance 
table. You need a configuration parameter to limit how far into the 
future events are added to the instance table. This needs to be 
configurable because some websites work just fine with only 1 year of 
future events visible and some websites needs events 5 years in the 
future visible.

How to make this work? The info table needs the recurring_data field 
to hold the info about when future events are. You also need a 
next_unrealized_instance datetime field. This field is null if all 
instances of the event are in the instance table. If however there 
are instances that exceed the cutoff date, this field contains the 
date of the instance that next exceeds the cutoff. Then you need a 
task in the scheduler to get a list of all events whose 
next_unrealized_instance datetime is greater than the now()+cutoff 
time. For each of these records, you add any missing future instances 
and update the next_unrealized_instance field.

All the logic to build your calendar views would shift focus from the 
current table to the instance table. But this also means that buttons 
like "edit" need to be split out into "edit master event" and "edit 
this instance". Outlook does this with a popup.

Part of the real problem is there is already pseudo-support for 
recurring events in that events can last multiple days. If you have a 
3-day convention annually, you generally aren't going to schedule it 
as a recurring event since the details from year to year are usually 
pretty much different even if the venue stays the same. But I'm sure 
someone will want to see support of attending Day 2 only. On the plus 
side, adding these events to the instance table simplifies the select 
code. Needless to say there are a lot of hidden gotchas to recurring events.


----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 



No virus found in this outgoing message
Checked by PC Tools AntiVirus (6.0.0.19 - 10.004.172).
http://www.pctools.com/free-antivirus/