At 11:14 AM 5/16/2006 -0700, Alec Flett wrote:
i.e. the zope adapter registry? is that built up at runtime or persisted
somehow in the repository?)
Built at runtime. Zope has some support for persistent interfaces, but
that's based on ZODB.
I don't think zope.interface will actually buy us anything for stamping,
unless I misunderstand what stamping is used for. Here's what I suggested
to Katie that our stamp implementation might look like... first, there's
an abstract base class for all stamps:
class Stamp(schema.Annotation):
schema.kindInfo(annotates=pim.Item)
# collection of stamp classes for each instance
stamp_types = schema.Many(schema.Class)
@property
def stamps(self):
for t in self.stamp_types:
yield t(self)
def add(self):
self.stamp_types.add(self.__class__)
def remove(self):
self.stamp_types.remove(self.__class__)
Now you can make stamp classes like:
class EventStamp(Stamp):
schema.kindInfo(annotates=pim.Item)
# event attributes here
# event methods here
And then do things like:
EventStamp(anItem).add()
or:
for stamp in Stamp(anItem).stamps:
# inspect and do stuff to the stamp object,
# or maybe remove it
This can all be done now, without any interface registration or anything
like that. Annotation classes work similarly to adaptation - if you ask
for EventStamp(ob) and ob is already an EventStamp, you get an equivalent
object. If it's an item or any annotation of the item, and it's a
compatible type, you get an EventStamp adapter object. In any case, you
then have an object with event attributes and methods (and only those
attributes and methods).
To answer Grant's question, this does not actually keep Kind composition
"under the covers" - it's based purely on the annotation
system. Annotation attributes are normal attributes, so they should be as
indexable as anything else. However, if performance considerations show
that storing stamp types as a set (e.g. as shown above) is detrimental then
some other way of tracking active stamps is needed.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
