[Chandler-dev] New conflicts API
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
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