[Chandler-dev] stamping as annotations?
Phillip J. Eby
pje at telecommunity.com
Thu May 18 13:57:53 PDT 2006
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
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
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".
More information about the chandler-dev