[Dev] Collections proposal: removing IndexedSelectionCollection

[Morgen Sagen]

In your proposal, if a collection is being rendered in two different  
tables, will there still be separate, per-table selections?  I think  
the answer is "yes", but I just want to be sure.

~morgen

On Feb 17, 2006, at 1:37 PM, 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:
>
> 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