[Dev] collections and notifications
vajda at osafoundation.org
Fri Mar 10 18:12:40 PST 2006
On Fri, 10 Mar 2006, Ted Leung wrote:
>>> The "collection item notifications" seem to have a distinctly different
>>> API than the other notifications. instead of 'subscriber.watchXXX(item,
>>> ..., methodName)' it is in the form
>>> Is there a reason it has this different API? The other methods are actual
>>> methods on the subscriber, rather than the item being subscribed to.
>>> Second, the other systems allow you to specify a method name, which seems
>>> quite valuable.. It seems like it would be nice to be consistent with the
>>> APIs across all the notification systems.
>> No particular reason other than history. I've been wondering about that
>> myself. Maybe I'll add a watchQueue(collectionItem, methodName) API....
> I think that something like watchQueue would be a good idea. Also,
> implementing transient subscriptions by indirecting of the itsView attribute
> is not very intuitive. Could you have a transient version of the method or
> pass a flag as an argument?
Hmm, dunno, I wanted to make it clear that it was for the view it was called
> On the collections API, you've switched a create at construction time model.
> Does this mean it will be impossible to restructure the collection tree,
> short of destroying a subtree and constructing an entirely new one?
Yes, that will be impossible without destroying and re-constructing. The way
the code was written before wouldn't have worked anyway, the hard part here is
that when a collection tree is modified in place, a large, potentially huge,
number of notifications have to be sent around (at least to maintain upstream
indexes). None of that was in place in the old code, except for the
add/removeSource method in collections.py, which is still there and still
works as before. Once we have a use case for such in-place collection
structure rearranging, beyond what is implemented and functional today, we
can reconsider this.
> In your post, the collections that you show descend from Collection but also
> need to have their __metaclass__ set to schema.CollectionClass, since this is
> always needed (if I understand correctly), is there a way to make it so that
> setting the __metaclass__ is unnecessary?
This is only needed for concrete base Collection subclasses. For example, in
osaf/pim/collections.py, the collection classes defined there need this
__metaclass__ but any of their subclasses wouldn't.
Basically, you need this __metaclass__ wherever you use __collection__.
It is my understanding that __metaclass__ is not inherited to subclasses, so
it has to be specified wherever it is needed, that is, wherever you use
__collection__ as well, in other words, wherever you declare the attribute
that is going to contain the wrapped set or ref collection value.
> Finally, I understand that using an explicit __collection__ attribute is more
> general, but if you look at the way that collections are used, the
> application will probably never make use of that generality. But now all
> the collection classes require passing tuples including __collection__
> arguments, which makes for more boilerplate code in the common case. It
> seems like there could be better defaults for the common cases.
Actually, no. With the bi-directional abstract set I recently added, it became
even more important not to hardcode this value. The designer of a collection
item subclass needs to have control over the name of the attribute the
set/ref-collection value that is being wrapped.
As for the boilerplate you're referring to, it could be removed if only
repository/item/Sets.py were to know about repository/item/Collection.py.
Consider that a bug :)
More information about the chandler-dev