Re: recurring events
Re: recurring events
- Subject: Re: recurring events
- From: Gavin Eadie <email@hidden>
- Date: Wed, 6 Feb 2008 14:44:36 -0500
Mike ... Do you get any ideas from the iCalendar representation of the calendar? I expect you've looked at this but, just in case, there in one definition for the recurring event -- the first VEVENT below, and others for any moved member of that series (the second VEVENT (same UID)). A removed event appears in the first VEVENT as a "EXDATE" line. There's variations on the theme, such as when a change is propagated to all future event in the series, that I didn't create.
BEGIN:VEVENT SEQUENCE:2 TRANSP:OPAQUE UID:0CD543D0-DFBB-46F2-BF48-37B43AA5DBA0 DTSTART;TZID=America/Detroit:20080204T150000 DTSTAMP:20080206T193203Z SUMMARY:New Event EXDATE;TZID=America/Detroit:20080208T150000 CREATED:20080206T193136Z DTEND;TZID=America/Detroit:20080204T160000 RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=MO,WE,FR;WKST=SU END:VEVENT
BEGIN:VEVENT SEQUENCE:3 TRANSP:OPAQUE UID:0CD543D0-DFBB-46F2-BF48-37B43AA5DBA0 DTSTART;TZID=America/Detroit:20080206T160000 DTSTAMP:20080206T193212Z SUMMARY:New Event CREATED:20080206T193136Z DTEND;TZID=America/Detroit:20080206T170000 RECURRENCE-ID;TZID=America/Detroit:20080206T150000 END:VEVENT
The above is the protocol in transmission, I've not looked at the way the server stores this info, or how the client keeps it in SQLite, but those too might offer hints to an approach that minimized that "huge pain" ... Gav
On Feb 6, 2008, at 11:37 AM, Mike Schrag wrote: I'm wondering if anyone has addressed modeling recurring calendar events with EOF in a nice way? None of the options seem particularly attractive to me at the moment, but I was hoping someone might have some clever insight into the problem. I think the proper impl is to make "ghost" events appear in the results that don't become "real" EO's until someone touches them to make a change from the original pattern, but this seems like sort of a huge pain with EOF ... I don't know what the overhead will be of constantly making and throwing away unsaved EOs on every view. I was considering a non-EO cover object for an event that can turn into an EO, but it means you have to "write it twice" to support all the API of the EO version of the event.
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden