Hi Chris! Thanks for your feedback. Chris McDonough wrote:
I'm a bit uncomfortable with the sort-by-subobject-attribute code in orderObjects (the code that is called when sort order is not "position").
I'm wondering if a generic "IndexedFolder" implementation might be better for this behavior, where the user may define one or more indexes on the container itself. The indexes could named after attributes of subobjects. The indexes and a sort function for each index would be maintained on the container, and the API methods objectValues, objectIds, etc.would consult the indexes to return objects in sorted order dynamically (as opposed to just returning the presorted list of _objects, which needs to be manipulated statically after each insertion).
Well, you could use 'orderObjects' for that use case if you write some code that does the necessary manipulation after each insertion. But we included it for another use case: Sometimes people want to maintain a user-specific order, but want to start from a sorted order. E.g. if most sub-objects should be ordered by 'title', but some special sub-objects should be at top of the container. I like your ideas of "IndexedFolder". And there are the two methods 'getDefaultSorting' and 'setDefaultSorting' in OrderSupport that do something similar in a very basic way.
This might be an argument to ditch the dynamic sorting feature until we better understand the use cases. That said, the feature isn't exposed in the mgmt interface, so it might be ok. But if people come to rely on it, it will be difficult to remove (and will never ever go away).
AFAICS, 'orderObjects' would still be useful for the use case described above. 'getDefaultSorting' and 'setDefaultSorting' provide a small subset of the API you propose and should play well with any "IndexedFolder". Cheers, Yuppie