[Design] Recurrence, table view, and triage status

Bryan Stearns stearns at osafoundation.org
Tue Sep 12 11:12:26 PDT 2006

Jeffrey Harris wrote:
> The first thing that comes to mind for me is that perhaps instead of
> always displaying the master, we want to display the next relevant
> occurrence in the table view, taking the current time and triage status
> into account.  I expect doing that would be quite a bit of work, but at
> least it wouldn't involve varying numbers of rows per item like
> displaying several occurrences alongside a master would.
There are a couple of places where this "instead" could be implemented, 
either centrally at the table-data level (anytime we do 
get-item-for-row, convert to occurrence -- or even proxy-wrap it too, 
saving work at higher levels), or in each attribute editor. (The former 
has the advantage that we could avoid putting equivalent code in the row 
operations -- delete, drag-and-drop, etc).

However, this facade breaks the notification mechanism: changes made 
elsewhere (in the detail view, triageStatus upon starttime being 
reached, sharing changes, etc) wouldn't trigger collection 
notifications; maybe the proxy wrapper could force an innocuous change 
to the master to trigger the notification, or generate fake collection 
notifications itself?

Or, as a separate suggestion, Is it time to reconsider whether 
occurrences belong in collections? (I'm under the impression that it's 
to simplify sharing, but since sharing already has to special-case 
private items in shared collections, maybe special-casing occurrences at 
the same level would be no harder?)


More information about the Design mailing list