Andi Vajda wrote:
On Thu, 9 Mar 2006, Alec Flett 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.
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?
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?
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?
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.
Ted
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
