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