[Chandler-dev] Dashboard domain model questions

[Bryan Stearns]

Thanks, Andi - comments inline ...Bryan

Andi Vajda wrote:
>
> On Thu, 29 Jun 2006, Bryan Stearns wrote:
>
>> Sorting
>> - New indexes, or indexing changes, to represent complex sort 
>> orderings like sectioned-triage (which has different sorts for 
>> sections, at least one of which is spec'd to order differently 
>> forwards and backwards) and the who/date/comm/reminder columns (which 
>> depend on presence/absence of many kind-specific attributes)
>
> One way to achieve this, possibly, is to use the little-known feature 
> of the AttributeIndex which can use multiple attributes to sort. Say 
> the first attribute is the section name, the second attribute would 
> then be used to sort the section and that one could be ascending or 
> descending. Dynamically changing the second attribute's sorting could 
> be costly though unless the section isn't too large.
Yes: I figure that ultimately the sort mechanism comes down to indexing, 
and it's just a matter of getting the index right. I didn't know how 
indexes were specified, so knowing that a list of attributes can be 
specified is good news; however, the ordering requirements are pretty 
complex... the communications column sort order is:
  - First: (Unread, Needs Reply, Read),
  - Second: (Created, Edited, Received, Draft, Queued, Sent, Error)
  - Third: (First-time, Update)
  - Fourth: (triage status: Now, Later, Done)
  - Fifth: (the order that triage status was last changed, most recent 
first)
  - and maybe Sixth: (UUID for tie-breaking)
  Note that the second term includes Kind-dependent attributes 
(Draft/Queued/Sent are Mail attributes), and if we do stamping with 
annotations, duck-typing them won't work.

I can certainly write a function (or set of functions, so that 
inheritance can help with the Kind-dependent part) to return a computed 
sort key, which is why I mentioned using a Calculated for the sort 
"attribute" (see below).

(Also, incidentally, it was a typo in the spec that led me to think that 
one of the triage-status sections was supposed to order differently 
backwards than forwards, so scratch that comment from my earlier 
message, and thanks to Sheila for clearing this up).

>
>> - Do we need specific Calculated methods for index-dependent dynamic 
>> values? (Does Calculated need to move to Schema for this?)
>
> What is a 'Calculated' method ?
Grant's answer, which just arrived as I was writing a worse one, is 
right; he said:
> I think Bryan meant "Calculated attributes" not "Calculated methods", 
> the API for properties (Calculated is a subclass of Python's builtin 
> property, with a couple of extra fields that aren't really used). One 
> example is CalendarEventMixin.endTime, which is calculated from the 
> startTime and duration attributes.
>
> See: parcels/osaf/pim/items.py, lines 64--80 for the implementation, 
> parcel/osaf/pim/calendar/Calendar.py for some code where it's used.
I'll add that two of the 'extra fields that aren't used' are used:
- there's a schema type, allowing a Calculated attribute to be presented 
using an attribute editor -- the attribute editor mechanism requires 
type information to pick which editor should be used.
- there's a list of dependent attributes, allowing us to set up 
item/attribute notifications to keep things up to date in the UI. If we 
use Calculateds for indexing, we might need the repository to hook into 
this so that indexes get updated when dependent attributes change - 
we'll talk about this more later.
>
>> - For later: how to model manually-set ordering in the table (when 
>> the user manually reprioritizes items by dragging them within a 
>> summary view)
>
> If this order is modeled by a ref collection (or a numeric index), the 
> order is persisted and can be arbitrary, ie, user chosen.
>
My concern was about the conflict that we've got a sort order already 
(see above example), and I'm not sure how to represent manual ad-hoc 
additions to it in the indexing mechanism, in an environment where items 
are moving around in the index automatically relatively frequently (as 
their triage status changes with the passage of time). If I manually 
position something to be first in the Now section, and three ticklers go 
off (moving their items to the top of the Now section because they have 
the most-recent triage-status change date), what piece of information 
causes that manually-positioned item to now be 4th? (Or is it still first?)