[Chandler-dev] Delaying reordering of items in the dashboard

[Bryan Stearns]

Thanks, John... I was hoping to find a solution that avoided changes 
across multiple layers of our architecture (especially since 
everything's being rearchitected now anyway, and since I got flack from 
specialized use of indexing in the past)... I don't think a previous 
version of an index would work, either, since it might contain a 
different collection of items from the current collection.


D John Anderson wrote:
> Perhaps the repository could postpone updating a particular index, 
> instead logging the changes which might get played back later to update 
> the index. As you point out, however, we'd have to think about what 
> would happen when items come and go.
> 
> Alternatively, If the repository versions indexes, maybe we could use a 
> previous version of the index instead of the current one.
> 
> John
> 
> On Nov 8, 2007, at 9:31 AM, Bryan Stearns wrote:
> 
>> In a discussion on the design list*, Mimi asked for implementation 
>> perspective for a change to cause all the columns to not reorder 
>> immediately when the user changes an item attribute that affects the 
>> current sort.
>>
>> The triage column currently does this, by keeping two sets of triage 
>> attributes: one set is always present, and controls the color of the 
>> triage button in the detail view and dashboard, and changes 
>> immediately when the user clicks on a button; the other set is only 
>> present when an unpurged triage status change exists on the item (eg, 
>> the user clicked on a button but hasn't clicked the Triage toolbar 
>> button yet) -- the index mechanism uses it in preference to the first 
>> set if it exists.
>>
>> One way to accomplish this change would be to double all the 
>> attributes this way - this probably wouldn't affect indexing 
>> performance too badly (though the index comparison functions would 
>> look pretty ghastly). However, I don't think this approach would scale 
>> well (and our items are already pretty heavy with attributes) -- 
>> however, I haven't thought of another approach yet. I'm also concerned 
>> with how new items (say, received by sharing) would get ordered in an 
>> unpurged collection.
>>
>> Anyone have any ideas?
>>
>> ...Bryan
>>
>> * 
>> http://lists.osafoundation.org/pipermail/design/2007-November/thread.html#7789 
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
> 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev