[Chandler-dev] Moving sharing-specific attributes out of
Phillip J. Eby
pje at telecommunity.com
Fri Jan 26 14:36:53 PST 2007
The simple solution is to:
1. Make Sharing a stamp
2. Make ContentItem.isAttributeModifiable() delegate this operation to its
stamps, returning the first false value, or true if all stamps return
true (i.e., the logical "and" of the stamps' answers
3. Add a default isAttributeModifiable() to Stamp, that returns True. This
will also fix the current issue where EventStamp appears to have an
isAttributeModifiable() method that delegates to a super(), but no such
4. Have the sharing code add or remove the Sharing stamp according to an
item's sharing status.
Per our discussion on IRC, I believe Morgen is now implementing this. (One
caveat: stamps that implement this must expect to see an attribute's fully
qualified name, so a stamp with an attribute 'foo' whose full name is
'some.where.SomeStamp.foo' will need to use the latter name in its logic
In the bigger picture, it may be possible to get rid of
isAttributeModifiable() (or at least the sharing aspect of it) once we have
conflict resolution, since it would no longer be possible for the user to
lose data accidentally.
At 02:09 PM 1/26/2007 -0800, Morgen Sagen wrote:
>On Jan 26, 2007, at 2:02 PM, Grant Baillie wrote:
>>On 26 Jan, 2007, at 13:55, Morgen Sagen wrote:
>>>To implement conflict resolution, I need to add a new sharing- specific
>>>attribute to ContentItem which will connect an item to
>>>its pending conflicts. I am actually going to do this by defining
>>>a SharedItem stamp and put the new attribute in there, but I was
>>>hoping to be able to also move two long-time sharing-specific
>>>attributes of ContentItem, "shares" and "sharedIn", into this
>>>stamp as well. This appears to be difficult because of
>>>ContentItem.isAttributeModifiable( ). That method needs access to
>>>the "sharedIn" attribute, and if I move that attribute into the
>>>sharing layer, some core pim code is now going to have a
>>>dependency on the sharing package which I believe we want to avoid.
>>You probably want just an Annotation, not a Stamp, I'm guessing.
>Ah, I thought they were one and the same, since I remember hearing
>the phrase "Stamping as Annotation" a lot. :-) What are the
>differences between a Stamp and an Annotation?
>>One possibility is to move isAttributeModifiable(), shares, and
>>sharedIn into your class. You can also refer to the sharedIn
>>attribute by its full name (which would end up being something like
>>'osaf.pim.MorgensClass.sharedIn'), though that seems crufty to me.
>If I move isAttributeModifiable( ) into my Annotation, and the pim
>calendar code relies on that method, the calendar code would have to
>import osaf.sharing, if I'm not mistaken.
More information about the chandler-dev