[Chandler-dev] New conflicts API

Morgen Sagen morgen at osafoundation.org
Fri Feb 9 19:09:26 PST 2007

I updated the conflicts API to its final state, and should be usable  
by the conflict resolution UI.  There is info about the usage on the  
Sharing wiki:


And also in the EIMML.txt doctest:


A conflict is an inbound change that overlaps with (and has a  
different value than) a local change not yet sent out. To see if a  
given item has any conflicts, you can check for the existence of the  
sharing.SharedItem(item).conflictingStates attribute. If that  
attribute exists, you can call sharing.SharedItem(item).getConflicts 
( ). That method returns a generator which yields Conflict objects.  
The Conflict object attributes that are relevant to a conflict  
resolution UI are:

    field -- a string indicating which field was changed
    value -- a string indicating the inbound value that was not  
applied because of a local change
    peer -- an item representing who the conflict is with; in the  
case of edit/update sharing the peer will be the Contact or  
EmailAddress? item (or whatever the mail layer chooses to use), and  
in the case of Cosmo-sharing the peer will be the Share item itself.

There are two methods on Conflict objects:

    apply( ) -- applies the pending change to the item
    discard( ) -- doesn't modify the item, but just throws away the  
inbound pending change

Note: "field" and "value" are not fully baked yet -- "field"  
currently always has value "Something", and "value" contains a user- 
unfriendly representation of the conflicting recordset. Real soon now  
we will produce Conflict objects for each conflicting field with  
friendlier strings. However, the API won't be changing, and the  
development of the resolution UI can proceed.

Also, I will be adding a way to easily create simulated conflicts for  
UI testing purposes.


More information about the chandler-dev mailing list