Hi Grant - see inline..
Grant Baillie wrote:
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?
It gets a collection notification (that an item in the collection being
displayed has changed).
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'"?
Yep - that's what I get for hitting reply before the coffee machine has
beeped to indicate that the elixir of clear and rational thought is ready.
- 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)]]
That sounds much better. Just propagating the notification makes sense,
especially if this lets us avoid storing the propagated values as I'd
suggested, which doesn't make sense in hindsight, for the reason Grant
gives:
There are costs associated with adding redundant attribute values to
the repository, and also with maintaining them correctly.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
