Andi Vajda wrote:
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
'collection.notificationQueueSubscribe(subscriber)'
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.
The original collection mechanism allow the subscriber to specify a
method name by adding an attribute with the name of the method to the
subscriber.
+1 for consistent API.
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?
+1 for a flag
Hmm, dunno, I wanted to make it clear that it was for the view it was
called on...
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.
I think we could get away with not sending any notifications when
rearranging the collection tree and recompute everything after the
rearrangement. Independent of whether or not the old code actually
worked, I suspect not allowing rearrangement will end eventually end up
biting us, but I don't think we should work on it until we end up with a
use case.
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 :)
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
