[Chandler-dev] Re: Stamping as annotation issues

Grant Baillie grant at osafoundation.org
Mon Jul 17 16:51:28 PDT 2006

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 :).


More information about the chandler-dev mailing list