[Dev] Collections proposal: removing IndexedSelectionCollection
alecf at osafoundation.org
Fri Feb 17 16:30:36 PST 2006
Morgen Sagen wrote:
> 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.
Yes.. it would be done with separate, per-table indexes I guess. Hrm.
But right now we have separate, per-table ISC's so its not like we'd be
any worse off...
> 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
>> 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]
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> Open Source Applications Foundation "Dev" mailing list
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Dev" mailing list
More information about the Dev