[Chandler-dev] [Sum] annotating selection
Katie Capps Parlante
capps at osafoundation.org
Tue Apr 4 20:30:10 PDT 2006
When writing the weekly summary for March 27 - April 2, the summary for
the "annotating selection" thread grew long enough to deserve its own
message. This is sort of an experiment in seeing if this kind of summary
Alec made a proposal to get rid of IndexedSelectionCollection (ISC). The
ISC's are created when a "SmartCollection" sidebar collection is
selected. A new ISC is created for every combination of
collection/kind/filter. The views need to refer back to the original
collection for color and other information. The ISC is used by the
summary table/calendar views for these purposes:
1. maintains the per-view selection, and persists the selection
2. container for storing indexes for source collection items
3. persistent storage of the current sort
Alec's argument is that the second 2 are not really valuable, and that
the third can be handled with "SelectionCollection" annotations (or some
Discussion about #2 (ISC storing indexes for source collection items)
Alec argued that indexes should be on the original collection, not on
John pointed out that some mechanism is required for different kinds of
sorts -- he gave different locales as an example.
Alec argued that this is a degenerate case, and that building an extra
layer of indirection is premature generalization. Alec argued we should
view an index more statically -- store different indexes ("date",
"displayName") instead of tweaking the indexes.
John remarked that he'd prefer not to store indexes by a well known
name. He'd like to be able to ask for an index by naming the properties
(building up a string or whatever). Indexes could be cached.
Andi pointed out that if we needed to store indexes for multiple locales
we could store multiple indexes, one per locale, all installed on the
same collection and named appropriately.
Andi asked if we really need to support multiple locales in the same ui.
Brian responded 'no' -- the indexes should use the sort order associated
with the "primary" locale. (There is a more complicated 'yes' answer,
"backup" locales are used for 3rd party parcels that don't support the
primary locale, but this does not affect the sort order).
Discussion about #3 (ISC persisting the current sort)
Alec argued that the current sort should be owned by the cpia block or
widget referencing the collection, not an intermediate collection.
John pointed out that we want a single block to be able to view many
different contents. John argued the selection is more closely tied to
the index of the collection than the Block.
Alec explained that his proposal would indeed allow a single block to be
used with different collections. Alec is proposing that the block store:
(a) contents, (b) name of the current sort index ("date") and (c) name
of the index being used for selection. The source collection would store
the different indexes by name. The block could swap contents, and the
indexes would be stored on the source collection. (see ascii art below)
Discussion about #1 (per view mechanism for persisting selection)
Problem to solve: how does the selection update automatically if it is
not part of the main collection? Annotations?
Alec gave some sample code in the original thread, and drew a diagram
that looked something like this when I asked him in person:
source collection <-- (contents) block
--> "date" sort index "current sort" --> "date"
--> "displayName" sort index "current selection" --> "dashboard"
--> "dashboard" selection index
Alec is proposing one consistent index that is used for selection in a
given block. The selection index would be independent of the sort
indexes. Its possible that we lose some efficiency, but we haven't yet
proved it necessary to maintain them together.
John asked if this is the tradeoff (waste less space at the expense of
- changing the selection for many items would be less efficient
+ if 2 different blocks use the same sort, we could reuse the index
John thinks it a mistake to give up on handling large lists efficiently.
More information about the chandler-dev