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
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.
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
instead.
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.
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 :).
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
