[Chandler-dev] Re: Stamping as annotation issues

[Phillip J. Eby]

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:

class StampItem(schema.AnnotationItem):
     stamped_items = schema.One(ListCollection)

class StampClass(schema.AnnotationClass):
     def _create_schema_item(cls, view):
         result = StampItem(None, view['Schema'])
         result.stamped_items = ListCollection(result)
         return result

class Stamp(schema.Annotation):
     ...
     @classmethod
     def getCollection(cls, repoView):
         return schema.itemFor(cls, repoView).stamped_items

And then, you should be able to assume self.collection is not None 
throughout the rest of the code, if I understand your intention correctly.


>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'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.


>Maybe a better approach is to change
>occurrences to _occurrences, and make occurrences a property à la
>stamps.

I don't know enough about the code being refactored to guess.  :)


>Anyway, comments (or ideas about the last paragraph of stream-of- 
>consciousness) are welcome. Also, if you'd prefer to hash things out
>on chandler-dev@, that would be fine, too.

I'm cc:ing this to chandler-dev since I prefer to err on the side of 
putting things in the archives.  That way, people learn about stuff, and 
it's Google-able later too.  :)