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,
--Grant
On 26 Jan, 2007, at 09:14, Bryan Stearns wrote:
Jeffrey,
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/
notifications)]]
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
dashboard
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
about
how best to remedy this.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
