At 01:35 PM 5/18/2006 -0700, Grant Baillie wrote:
In the the annotation scheme of doing things, is there a way for different kinds to customize behaviour when getting stamped? For example, a certificate might want to encapsulate itself as an attachment when stamped as mail, whereas events turn themselves into invitations.
Sure, you can delegate some behavior back to the underlying item, via the annotation's ``itsItem`` attribute. That is, a method on the Stamp can call back to a method on the original item using ``self.itsItem.whatever()``.
BTW, the other thing in Katie's email that brought the whole interface/adapter model to mind, and maybe a more compelling place than stamping, was having items adapt themselves when being displayed in different contexts in the UI.
I would translate that as the UI asking for annotations that are specific to the display context, but certainly adaptation is a possibility there as well.
The point of using Annotations isn't to substitute for adaptation, it's to annotate items with additional data. Stamping itself meshes well with that concept. Adaptation is an somewhat-independent concept that might also be useful for various things.
Adaptation by itself, however, is *not* a solution to the stamping problem, because it doesn't address how additional attributes get stored, indexed, displayed, etc. Annotation solves that problem nicely, and also can do many of the things that can be done with annotation. The rest of the things that adaptation does can likely be handled by adding some extra features to the Stamp base class, for example to return all the stamps that implement some interface.
I feel I should mention, by the way, in case there's any appearance of conflicted interest, I actually am a co-author of zope.interface (i.e. I wrote the zope.interface.advice module) and much of the current implementation of zope.interface is based on design ideas either borrowed from PyProtocols or based on an API and terminology design that I significantly contributed to. So, either way you're going to be using my code and/or design here. ;-) I just mention this so nobody gets the impression I'm arguing for the Annotation approach because I wrote it. The real reason I'm arguing for it is that I wrote it specifically for Chandler, the repository, and stamping.
Adaptation can do some cool things too, but I'd be wary of introducing interfaces and adaptation into the pool of things that developers have to understand in order to play in the platform. I'd want to see whether less-general mechanisms that are more specific to our platform could work first, so that instead of having to learn interfaces and adaptation to do stamping, you just "learn to do stamping".
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
