[Dev] Collections proposal: removing IndexedSelectionCollection

[John Anderson]

Alec Flett wrote:
> 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:
I already added Andi's set of APIs to AbstractCollection and have been 
using them pretty much as you're describing them.

The plan was to move a bunch of the display/sharing attributes to 
annotations. We could move the table index along with it's methods (I 
don't know if annotations can include methods as well as attributes). 
However, if we end up with a single Collection class, a mixin might be 
better.
>
> 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