Community
Participate
Working Groups
The Dawn component of CDO provides an infrastructure for adapting GMF's transactional editing domain for diagram editors to CDO's transaction model. It also provides edit-part/edit-policy support for handling remote object updates, conflicts, etc. Papyrus needs to provide extensibility hooks for injection of CDO integration adapters into its diagram editors, along with specific implementations of Dawn API required to handle CDO remote interactions.
I'll take this (work already in progress).
r9983 on cdo_kepler branch: Defined an IGraphicalEditorSupport service that enables injection of CDO-specific hooks into a GMF-based editor. The default implementation does nothing, but the CDO implementation will attach various Dawn editor-support adapters and stuff to the editor. After creating the diagram IEditorPart, the GmfEditorFactory obtains the IGraphicalEditorSupport service and installs it on the editor. This should eliminate the need for generating Dawn fragments with subclasses of every Papyrus diagram editor and various edit parts (which Dawn offers primarily for external integration into CDO of third-party editors).
r9997 on cdo_kepler branch: Initial implementation of Dawn integration into Papyrus's GMF-generated diagram editors, including the following components injected by an implementation of the new IGraphicalEditorSupport service: * PapyrusGMFEditorSupport - installs CDO transaction handlers for updating editors to reflect changes committed by remote clients * PapyrusGMFHandler - specializes the DawnGMFHandler to post diagram refreshes asynchronously for UI-thread-safe access to GEF figures from Papyrus's edit-parts
In r10061 on the cod_kepler branch, we now have decorations in the diagrams (shape edit parts, not yet edges and text) and the Model Explorer for CDO object states: - conflict (dirty updates on an object committed by a remote transaction) - locked remotely (remote transaction reserves modifications on an object) - locked locally Conflicts and remote locks are shown as and when they are reported by the CDO Server on-the-fly. Remotely locked objects are not editable; this is accomplished by - adding an isReadOnly(EObject) query to the ModelSet API and using this in the related EMFHelper API. The default implementation in the ModelSet just checks whether the editing domain has the containing resource as read-only; the CDOAwareModelSet checks for remote locks on the object (object-level permissions check TBD) - updating the IElementEditServiceProvider to return a non-editing service for read-only objects (as determined by the ModelSet) Context-menu actions in the diagrams and Model Explorer provide the means to Lock and Unlock objects (locally, of course) and to resolve conflicts (currently only by rolling back the transaction).
Now r10062 has CDO object state decorations on edges in the diagrams, too.
r10380 This enhancement has been merged into the trunk.
