Detail View Notifications

A few notes about how the detail view uses notifications internally and externally, to augment an upcoming discussion...

The detail view uses notifications at two levels: per-whole-detail-view and per-attribute-editors.

A couple of definitions:

• The detail view is the hierarchy of blocks installed underneath one of two BranchPointBlocks in our UI (either the one provided next to the Calendar view, or the one provided next to the Summary Table view). The top of this hierarchy is always a DetailRootBlock; this block is marked as an event boundary.

• I'm considering the BranchPointBlock above the detail view to not be part of it.

Per-Whole-Detail-View Notifications

The detail view's model is currently to display one item; it receives that item via a SetContents event, relayed to the detail view by the BranchPointBlock above it after the BranchPointBlock has built (or selected from a cache) an appropriate detail view based on that item's Kind.

(more info here about the stamping case, and what causes the detail view to change then.)

Per-Attribute-Editor Notifications

In the detail view, editing functions are provided by attribute editors; each attribute editor is hosted by an AEBlock -- actually, an AEBlock subclass called DetailSynchronizedAttributeEditorBlock (hereafter DSAEBlock). This subclass adds notification-management behavior.

There are two reasons why a DSAEBlock might need to be notified:

• an attribute value that affects the value displayed might've changed (obviously, if the displayed item's 'about' attribute changes, the text in the Headline block would need to be updated; more delicately, if the item's 'anyTime' flag becomes set, the StartTime and EndTime editors need to replace their values with the "hh:mm PM" hint). Value changes are relayed to the attribute editor itself by DSAEBlock.

• an attribute value that affects visibility of a block might've changed (eg, if the user changes the 'allDay' field, the StartTime and EndTime blocks need to hide themselves). Visibility is managed at the DSAEBlock level.

It's important to realize that these value change notifications can come because of value changes both inside and outside the detail view: the detail view doesn't distinguish between a notification caused by an item change received in sharing synchronization and one received because the user edited something in the summary table view.

Note also that the detail view is setting attribute values as the user edits: currently, we write edits to the item immediately for all editors other than the text controls; we write text control edits when the control loses focus.

In the note body, we used to also write edits back when the user hit 'enter', but this caused a problem when notifications were asynchronous: the body attribute editor receives change notifications caused by its own attribute-value changes, of course, and when those notifications would arrive later -- after more keys had been hit by the user, making additional un-written-back changes to the text in the control -- those additional keystrokes would be lost when the control reloaded itself.

(Note to come about how we're using repository monitors now, and how they're not suitable for this: they don't generate notifications for changes that come from other views at refresh() time)