[geeklog-devel] Calendar Plugin - Recurring Events

[Anthony Rowles]

It's an important policy decision, for certain.  According to W3C, >95% of
users browse with JavaScript enabled, and this percentage rises every year.
Still, we should probably support graceful degradation - the parser would
have to be written twice in PHP and JS, but it shouldn't be too difficult to
port just a few classes, and it's functionality anyone with knowledge of PHP
and JS could add later, if I don't have time during the summer.  I'd
implement the fallback solution using temporary tables - this prevents the
generated events from interfering with the client-side solution, and since
the number of JavaScript-disabled users is likely to be extremely low, the
lack of caching shouldn't be an issue.  A user with JS disabled is going to
have a less responsive application, but a functioning one.

- Tony

On Thu, Apr 1, 2010 at 1:15 PM, Vincent Furia <vfuria at gmail.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20100401/b1b89fa2/attachment.html>