On 17 Jul, 2006, at 16:37, Phillip J. Eby wrote:
At 03:28 PM 7/17/2006 -0700, Grant Baillie wrote:
Hi, Phillip
So, I put together a try at doing the stamping-as-annotation
thing, in
<http://svn.osafoundation.org/sandbox/grant/stamping/>
There have been a couple of tricky things,
1. We'd talked in the email thread about having a ref collection of
all the items with a particular stamp. For the moment, the way you do
that by defining a str, __collection_name__ in your annotation
subclass, that says where to put the ListCollection. (In general, the
code here is a little cheesy: I had to override _create_schema_item()
to install the collection, but there's probably a better way). Having
the collection feature be optional in this way was really kind of an
API hack to get my little doctests running, though.
I think that probably the right thing to do here is to also
subclass schema.AnnotationItem, and put the collection there.
Maybe something like this:
...
Cool, that looks good.
2. In the implementation of Stamp.delete(), I had to go and del the
Annotation's attributes. I'm not sure if I actually did that
right :).
I thought removing a stamp was supposed to keep the attributes
intact, and that if a stamp really needed to delete the attributes,
it could do so by overriding remove() and deleting them before a
super call to the original remove(). As you've written it, it's
impossible for a stamp to retain values after removal.
I think there was concern in the past that that would leave dangling
(otherwise unreachable) objects in the repository, like reminders to
events that appear nowhere in the UI. Still, it seems to me that any
of the possible behaviours (leaving the attributes around so that re-
stamping is like restore, deleting the attributes, or having stamps
delete selected attributes) is implementable.
I've also started looking at implementing this in the rest of
Chandler, but there's at least one sticky point: The recurrence
implementation declares attributes that refer back to
CalendarEvent (Mixin). So, right now, there are things like
class CalendarEventMixin(...):
occurrences = schema.Many("CalendarEventMixin",
inverse=occurrenceFor, ...)
So far as I can tell, there's no way for me to say
class EventStamp(Stamp):
occurrences = schema.Many("EventStamp", inverse=....)
since "EventStamp" isn't persisted directly by the repository. Or
will the schema API magically take care of destination types that are
Annotation classes?
I believe it should, though I wouldn't swear to this exact
scenario; let me know if it doesn't work. :)
Actually, even if it did, I doubt it could
decorate occurrences on the fly from a ref collection...
Well, it doesn't need to, but of course the items you get back will
be the base items, not the stamp wrappers.
I'm guessing I'd have to go through the code that uses things like
occurrences and add the EventStamp() as needed.
Yes, to reference stamp attributes you have to cast to the
appropriate stamp type. This will require client code refactoring,
but of course you statically know whether you are accessing a stamp
attribute or not, so this just makes it more explicit.
...
OK, thanks for the answers; I'll press on gamely :).
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
