Big picture implementation?
dwayne
looks promising. I'd love to get some "big picture" feedback on how to
implement it. (Since I found no tutorials, this also could be helpful
to others who are looking for a starting point.)
1. Database representation
I've read Rick's Jan 09 post on modeling for the database. So, as I
see it, I'd have an events table with only three fields, something
like this Rails schema:
create_table "events", :force => true do |t|
t.datetime "start"
t.datetime "end"
t.string "ical_string", :null => false
end
add_index "events", ["end"], :name => "index_events_on_end"
add_index "events", ["start"], :name => "index_events_on_start"
The start and end fields would map to the beginning of the first
occurrence and the end of the last occurrence, respectively.
To display a calendar over a given time, I pull all events between the
start and end. All other info will be pulled when I iterate over the
occurrences.
One question about this: What if I want to filter my calendar on other
fields as well, not just time period? For instance, if my users want
to search by location, I might want to duplicate the location in the
database, not just embedded in the ical_string. That way, it could be
indexed and make for much faster, leaner queries. Is this just a
balance I need to strike?
2. Recurrence
The "every event is a recurring event, even if it occurs only once"
approach makes sense for consistency.
So if an event only occurs once, do you create an RRULE with count 1?
Is that the preferred practice for using the OccurrenceEnumerator?
3. Exceptions
When a user wants to make an exception to an occurrence (this will
happen most often with cancellations that will remain displayed), I
see two ways to do this:
- Split the event into three pieces: (1) The occurrences up until that
occurrence will be one event; (2) the 'exceptional' occurrence will be
its own event; (3) the occurrences after that will be an event.
- Keep the event as is and track exceptions in a different table. To
display a month, I'd have to enumerate the occurrences, then go back
and write over the ones that have been altered.
Am I right that the former is the preferred method?
Thanks for any feedback.
Rick DeNatale
That's up to you and your particular application requirements. Once
we start working on the 'eventually' project, we should consider
requirements coming from use cases like this.
> 2. Recurrence
>
> The "every event is a recurring event, even if it occurs only once"
> approach makes sense for consistency.
>
> So if an event only occurs once, do you create an RRULE with count 1?
> Is that the preferred practice for using the OccurrenceEnumerator?
There's not need to. Just make a normal event without any rrules and
RiCal will treat it as an event with one occurrence and the
enumeration methods should "do the right thing" <tm>
> 3. Exceptions
>
> When a user wants to make an exception to an occurrence (this will
> happen most often with cancellations that will remain displayed), I
> see two ways to do this:
>
> - Split the event into three pieces: (1) The occurrences up until that
> occurrence will be one event; (2) the 'exceptional' occurrence will be
> its own event; (3) the occurrences after that will be an event.
>
> - Keep the event as is and track exceptions in a different table. To
> display a month, I'd have to enumerate the occurrences, then go back
> and write over the ones that have been altered.
>
> Am I right that the former is the preferred method?
I'm pretty sure that that's how most calendar servers using caldav do
it, although I might be wrong.
--
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
dwayne purper
--
Dwayne Purper