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

[Grant Baillie]

Hmmm... I'm not sure that's the simplest solution, though:  
essentially this adds a new stamping feature.

I agree the EventStamp.isAttributeModifiable() implementation is  
useless as it stands. But, do any stamps need to override what's on  
ContentItem? The existing code would probably work with occurrences  
(since the 'sharedIn' attribute is inherited from the master). And,  
if it doesn't, it's straightforward to override isAttributeModifiable 
() in the Occurrence class.

--Grant

On 26 Jan, 2007, at 14:36, Phillip J. Eby wrote:

> 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
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev