[Chandler-dev] Moving sharing-specific attributes out of ContentItem

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 
method exists.
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 
within isAttributeModifiable().)

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.
>>>
>>>Any ideas?
>>
>>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.
>
>~morgen



More information about the chandler-dev mailing list