[Chandler-dev] stamping as annotations?
grant at osafoundation.org
Mon May 22 11:46:45 PDT 2006
On May 18, 2006, at 1:57 , Phillip J. Eby wrote:
> 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
>> 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.
Yeah... that's a little longer-term of a problem than "fixing stamping".
> 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.
Agreed. My plan, then, will probably be to try a stamping-as-
annotation implementation first. If it turns out there's a lot of
ugly messing about with self.itsItem to do customization, then it
might be right to think about adaptation. More likely, what will
happen is that different, largely unanticipated issues will come up
> 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
Cool: thanks for the clarification. I hadn't realized you'd been
devious enough to implement the underlying technologies for both your
proposal and the alternative :).
More information about the chandler-dev