[geeklog-devel] Calendar Plugin - Recurring Events

Vincent Furia vfuria at gmail.com
Thu Apr 1 13:15:26 EDT 2010


Tony,

I like the idea of having the client do the work. But what happens if the
client has JavaScript disabled? Will they be unable to view recurring
events?

-Vinny

On Thu, Apr 1, 2010 at 11:01 AM, Anthony Rowles <aqrowles at gmail.com> wrote:


> On Thu, Apr 1, 2010 at 9:38 AM, Samuel Leathers <sam at theleathers.net>

> wrote:

> > I think having a bunch of columns for recurring events could get real

> > ugly. My other thought was what if we mirror the ical structure in the

> > database like so:

> >

> > columns: dtstart, dtend, rrule

> >

> > And then write an ical class with a parser for displaying calendar

> > events. This could be slow (I don't know), but what if we augment this

> > ical backend in the database with a cache?

>

> I'm also writing a proposal for the calendar plugin, and I'll get into

> this in more detail there, but my design uses this approach for

> calculating recurring events - except I plan to do that work in the

> client (free scaling!). It'll almost certainly be faster than having

> the server do all the computations, and at the very least the wait

> time will occur after the page has loaded, giving the user something

> to look at while they wait for the events to populate, instead of

> staring at a blank page.

>

> I plan to store recurring events in a separate table, but with one

> additional field, a list of "exceptions". When the client requests

> events for a range (say, April 2010), it gets a set of single events

> for that range, and a set of recurring events that might fall in that

> range (based on dtstart/dtend). It then generates all instances of

> the recurring events that take place within the range it's currently

> displaying (in this case, April 2010), and adds those to its event

> list. If the user wants to change one instance of a recurring series

> (say, move next week's weekly meeting back one hour because of a

> conflict), we convert the event to a "single event", add it to the

> non-recurring table, and add the date/time to the list of exceptions

> for its parent recurring series. You just have to maintain a link to

> the parent in the database so you can delete the newly spawned "single

> events" if the user later wants to delete the entire recurring series.

>

> Here's a really great paper on the topic that describes a flexible way

> to write a recurring event parser (what he calls "temporal

> expressions"): http://martinfowler.com/apsupp/recurring.pdf. His

> examples are in Java but I think it can be done just fine in

> JavaScript. Using unions/intersections/differences between sets, you

> can create really powerful and complex recurrences (every 3rd week in

> the summer, etc) fairly easily.

>

> - Tony

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://eight.pairlist.net/mailman/listinfo/geeklog-devel

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://eight.pairlist.net/pipermail/geeklog-devel/attachments/20100401/1b89983b/attachment.htm>


More information about the geeklog-devel mailing list