[Chandler-dev] Re: annotating selection

[Alec Flett]

John Anderson wrote:
> We originally considered doing this and it can be done. However, two 
> different users may want to have a sort named "date" that works 
> differently, e.g. one date sorts using one locale and another sorts by 
> another locale. So as long we build in a mechanism to resolve how 
> different names map to the same or different sorts it's fine. We 
> choose the current mechanism because it was easier than implementing 
> such a mechanism.

this is a degenerate case. If we need that case we can build something 
in where the index name is "date_en_US" or something, but I think 
building an entire extra layer of indirection to support this seems like 
premature generalization to me.

In general, I view an index as a sort of static sort of items.. When you 
have a bunch of unrelated indexes like "date", "displayName" an so 
forth, then we shouldn't be tweaking what individual indexes do, but 
rather choose the right index from the pool of those available to us.
> Storing the selection on the block leads to the following problem: 
> Consider the case where you want a single block that is used to view 
> many different contents (I think the calendar currently works this 
> way). If you store the selection on the block then your selection 
> becomes incorrect when you switch to a new contents. Storing the 
> selection with the contents allows you to restore the collection. 
> Personally, I think the selection is more closely tied to the index of 
> the collection that makes up the contents, rather than the Block.
Maybe I wasn't clear in my proposal. I did not suggest storing the 
actual selection on the block, but rather the name of the index on the 
collection that is used for selection in that particular block.

For instance, the dashboard block might store its current selection in 
the "dashboard" index in self.contents. I did fail to mention that this 
index would be a numeric, unsorted index independent of other shared 
indexes like "date" and "displayName". A block's self.contents could 
change, to become a different collection, with a different "dashboard" 
index with a different selection... so swapping in different collections 
would work just fine. If some specialized block comes along called 
"spiralview" then it could store its selection in the collection in the 
"spiralview" index.
>>
>> The tricky case is 1). How do we keep selection off the main 
>> collection and yet have it update automatically when items are 
>> added/removed from the collection? I thought first about Annotations. 
>> We still haven't solved the problem of how to maintain selection when 
>> changing the current index, so perhaps instead we could think about 
>> the selection as a sort of Annotated dictionary-style attribute, 
>> keyed off of some part of the block. Basically you'd be hanging a 
>> bunch of selections off of the collection,
> It's not difficult to maintain the selection when switching the index 
> -- it's a task on my list that I haven't finished doing.
Right, so I'm proposing a mechanism: have one consistent index that is 
used for selection in a given block. Make that index independent of the 
currently selected items.

Its true we'd loose the efficiency that might be gained by making the 
table's selection ranges match the table's sort index, but we've never 
actually shown that we need that efficiency. Just trying to avoid over 
engineering this in the name of premature optimization :)

Alec