Hi Ted, > On May 11, 2005, at 12:12 PM, Jeffrey Harris wrote: > >> It seems to me that the options for having the calendar view see >> occurrences of indefinitely recurring events for 20 year in advance >> are: >> >> 1) Make the view responsible for creating the relevant occurrences >> (yes, I know, thunderous -1's from the list) >> 2) Make the query system responsible for generating the relevant >> occurrences >> 3) Generate enough events that we're sure the apocalypse will have >> arrived before we run out (I support avoiding theology in Chandler :) >> 4) Don't generate occurrences past a certain point, warn the user >> visually if they're past that point >> 5) Get the model/view contract refined to the point that we can use >> proxy objects and avoid generating occurrences
Ted Leung wrote: > If you do something like 4), with or without an end date, then all it > takes for queries to do this "automatically" is for the query > processor to call the method that generates occurrences, at least if > you are asking for occurrences that match a date range. What I was envisioning for 4) (but didn't elaborate clearly) would be that our data model act as if indefinitely recurring events more than, say, 3 years in the future don't exist. We would preserve the fact that they're indefinitely recurring, all the relevant occurrences would be updated nightly and exist as fully fleshed out first class items. So in my picture of 4), the query system wouldn't need to have any semantic understanding of recurrence. Having a definite end point would allow us to provide a warning to the user in the Calendar View once they'd browsed their calendar past that point, something like, "You're viewing dates more than three years in the future. Please note that indefinitely recurring events are only displayed for three years." I'm really circling in on this option as the way to go in 0.6, it deals with what I think are the common use patterns without placing much burden on the existing framework. Do other folks agree that this is the right path to follow for 0.6? Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
