So we've been working with IndexedSelectionCollection for a while and
I'm finding that it is very useful, but I think we can make this a
little simpler, and remove an extra level of collections at the same time.
Background: IndexedSelectionCollection (hereafter "ISC")was created to
maintain a current selection and sort order in a collection, without
affecting the original collection. Generally selection and sort order
are considered UI or "view" level details, and it made sense to separate
that out from the original collection.
So right now if you want to display a collection in the summary view or
calendar, an ISC is created which "wraps" the real collection in the
sidebar. It does this by simply referencing the original collection the
same way a UnionCollection might reference "child" collections. This is
the collection that the calendar or summary table view uses to iterate
items, maintain selection, etc. The 'indexName' attribute of the ISC is
the name of an index stored on this collection. There can actually be a
bunch of indexes on the ISC because you might, for example, sort by
date, and then sort by subject, and then sort by author.
The problem: we'd like to move things like "Color" off of
AbstractCollection and into some kind of "User Level Collection" or at
least some kind of Annotation on certain existing collections. The
problem is that with this extra ISC, its unclear where "color" really
belongs. ISC's are in a sense transitory - used only for maintaining
information about the view. Plus you get a new ISC for each combination
of Kind Filter + Collection. So really 'color', among other things,
belongs back on the original collection.
Another major problem is that the only (obvious) way to attach an index
to a collection is simply by setting "indexName" - (sure you could call
contents.rep.addIndex(...) but that seems to miss the point) - which
means you're pretty much stuck with the kind of indexes that the ISC
knows how to create, which are only attribute indexes. In 0.7, we're
going to be doing some interesting things with the dashboard that are
going to require some clever new types of indexes - indexes that the
Table should know about, but that basic Collections should not.
Further, because ISCs are independent of their underlying collection,
indexes that might be useful elsewhere in the app are stored on this
presentation object rather than the real collection.
Solution: What I'd like to propose instead is that we get rid of this
notion of 'indexName' on the ISC, and instead provide APIs on
AbstractCollection much like Andi's existing set APIs, that provides
direct access to the indexes. Instead, the concept of 'indexName' should
be an annotated value (lets say part of a schema.Annotation called
'TableData' or something) that its consumers use - for instance the
table summary view could put an annotated attribute "currentTableIndex"
on the collection and the access items in the collection like:
tableData = TableData(currentTableIndex)
# use index()
indexOfItem = contents.index(item, tableData.currentTableIndex)
# or use iterSelection()
selection = contents.iterSelection(tableData.currentTableIndex)
This allows us to all use the same original collection with annotations,
and places the responsibility of creating the right indexes in the hands
of the code that will use it - like the table, rather than in some
intermediary collection.
The other thing this allows us to do is attach these
"AttributeCollators" that I proposed earlier, and keep them at a
higher-level than AbstractCollection. For instance to get a special
collator for time you might say:
dateSorter = AttributeCollators.getCollator('startTime')
contents.addIndex('magicDateSort', dateSorter)
(where dateSorter is somehow magically transformed into something that
the repository understands.. a detail to work out later)
then later you could say
itemIndex = contents.index(item, 'magicDateSort')
Again, this is now possible because the responsibility for creating
indexes is in the hands of the consumer.
Thoughts? I think this is something that might want to wait until Andi
has moved more collections stuff "below the line"
[We don't need to get into too involved of a discussion on the list as I
sense this is a hot topic and would be better discussed in person - but
I wanted to put this out here while it was still fresh in my mind]
Alec
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
