[geeklog-devel] Calendar Plugin - Recurring Events

[Joe Mucchiello]

At 02:27 PM 4/1/2010, Anthony Rowles wrote:
>Content-Type: multipart/alternative; boundary=0016e64cd4fa0e32b00483310549
>Content-Transfer-Encoding:
>
>If a user is downloading a calendar side block for the current 
>month, and there's a 10 year old weekly meeting in the database, the 
>user would either need to download one copy of the recurring event 
>or four instances of the event that have been populated into the 
>database.  Calculating the recurrence on the fly results in a page 
>size decrease.
>
>The problem I think you're talking about isn't really with 
>long-lasting events, but with infrequently recurring events.  There 
>are definitely use cases where this could be a issue - for example, 
>a calendar of all employee birthdays for a large company.  A 
>monthly-view side block would have to receive every employee's 
>birthday in order to check if any occur during that month.  When I 
>wrote some calendar software for a government contractor that had to 
>deal with a lot of quarterly and annual reports - what I did was 
>flag events with the months they could possibly occur in, and use 
>that as an additional filter.  This limits your recurrence 
>possibilities somewhat ("every 42 days" would be impossible to 
>implement, for example), but it's not a bad trade-off.

This is why if you precalculate it all once (when the item is saved) 
then all access to a set of events is not only faster but the code is 
SIMPLE to maintain. The every 42 days event works just fine if it is 
pre-calculated once. Then any time someone selects a range of events 
(May 2011 for example) if there is an event in that month that 
matches the calculation cost during the select is just one more row 
as opposed to a lot of date manipulation.

A complex morass of exceptions that has to run on both the client and 
on the server is not something the core devs should have to deal with 
4 years from now when perhaps you have moved on. If all the code is 
in one place and only ever has to run while the user creating the 
event is saving the event, it makes the code easier to maintain going 
forward. I think the agile programming folks call this the DRY 
princicple: Don't Repeat Yourself.


----
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/