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
Does this seem like a complete list?
I've been convinced that 5) is overreaching for 0.6. 1) is inelegant and liable to incite insurrection.
2) seems fine to me, I don't know if it would be OK with Ted.
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.
However, if you are doing a query that looks for all occurrences related to "Foo",
then you might end up with a situation where the query result should contain
occurrences that have not been generated yet.
So, for date range queries, I think it's possible for queries to generate occurrences
on the fly. For other attribute based queries, I'm not so sure. Note that the problem
I mentioned above exists even if queries don't try to do the generation -- they are just
calling the "make enough occurrences" method.
---- Ted Leung Open Source Applications Foundation (OSAF) PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
