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?)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
