public
Description: Models discrete and recurring events
Clone URL: git://github.com/dball/acts_as_calendar.git
name age message
file README Thu Jun 12 22:16:31 -0700 2008 initial overview [dball]
file Rakefile Thu Jun 05 16:24:04 -0700 2008 data models [dball]
directory app/ Fri Jun 13 14:15:49 -0700 2008 adding rrules tests [dball]
directory config/ Thu Jun 12 21:58:24 -0700 2008 adding ical support, unit tests for recurrences [dball]
directory db/ Thu Jun 05 16:30:31 -0700 2008 adding migrations and schema [dball]
directory doc/ Thu Jun 05 21:24:05 -0700 2008 adding rails skeleton for good measure [dball]
directory lib/ Thu Jun 12 21:58:24 -0700 2008 adding ical support, unit tests for recurrences [dball]
directory public/ Thu Jun 05 21:24:05 -0700 2008 adding rails skeleton for good measure [dball]
directory script/ Thu Jun 05 21:24:05 -0700 2008 adding rails skeleton for good measure [dball]
directory test/ Fri Jun 13 15:03:30 -0700 2008 adding test for multiple weekly recurrence rrules [dball]
directory vendor/ Thu Jun 12 21:38:37 -0700 2008 moving generators to exemplars, adding beginnin... [dball]
README
== Acts As Calendar

This rails plugin aims to provide support for calendar events, both discrete and recurring. The goal is to be able to 
attach a calendar to any model object, and to attach calendar events to any of that object's children or possibly 
descendents. The calendar data should be publishable in ical format, and possibly editable from as well, to the extent 
that the data model allows.

Events may occur on specific dates, recur monthly on a given day (the 15th), a given day of a given week (1st Thursday, 
Last Saturday), or a given weekday (Every Friday), or any combination of the above.

Recurring events are stored as patterns in the database, and are joined against a table of dates, decomposed into parts, 
into a view of event instances. This has the advantages of being easy and efficient to query, and of bypassing the 
typically non-standard database date functions. The disadvantage, of course, is that it requires a table of all 
potential dates against which to join. That being said, a century's worth of date data should only be a few hundred 
kilobytes, not large by today's standards. The limiting factor at the moment is in initially populating these data, it's 
fairly slow with ActiveRecord.