[Chandler-dev] Recurrence and changes to masters in the dashboard
grant at osafoundation.org
Fri Jan 26 09:52:35 PST 2007
Howdy, Bryan and Jeffrey: Thanks for your postings. To start out
with, a general question for the masses:
How specifically does the Table currently know when to redisplay items?
More inline below in Bryan's message,
On 26 Jan, 2007, at 09:14, Bryan Stearns wrote:
> If the only attribute we're setting on the master that we should be
> setting on the occurrences, we could do either of these things:
Hmm... I've re-read the first clause of this sentence a couple of
times, and I still don't understand it :(. Did you mean "... we
should be setting on the occurrences is 'read'"?
> - Observe 'read', and if it's set on a recurrence master, propagate
> the setting to all the occurrences when the observer fires
It seems to me that the repository should propagate notifications(*)
of inherited values; i.e. if I change x on the master, I should get
notifications for each occurrence that doesn't have its own value for
x: since effectively those values are changing, too. Note that this
is an issue not just for "read", but any attribute that contributes
to the display of the summary table.
[[(*) I'm intentionally being lazy with the word "notification" here;
really I mean any notification of changes (i.e. watchers/monitors/
Essentially, what I'm saying is that the first pass at the
"inheritFrom/inheritTo" has the API in a inconsistent state: the
repository takes care of getattr() inheritance, which is what we care
about in an object model. However, other repository features
(e.g.RepositoryView.findValues(), collection reindexing,
notifications), are completely unaware. For findValue(s): we have a
higher-level, but completely parallel API that does the extra lookups
in the case where attributes are inherited. Are there ever cases
where you would not want inheritance to be followed?
> - Special-case recurrence masters in the code that sets the 'read'
> flag, and manually propagate the setting to all the occurrences if
> the target is a recurrence master.
> (I prefer the latter: While it couples tighter, it seems lighter-
> weight than the former)
There are costs associated with adding redundant attribute values to
the repository, and also with maintaining them correctly.
> Jeffrey Harris wrote:
>> Hi Folks,
>> I'm working on bug 6702, "Clicking on recurring events in the
>> doesn't mark them read".
>> In fact, the events do get marked read, but it's their master event
>> that's marked read (so read/unread applies to all occurrences).
>> This is
>> the desired behavior.
>> The problem is that changes to masters doesn't cause notifications to
>> fire in the table. I wanted to start a conversation on the list
>> how best to remedy this.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev