Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 340627

Summary: Features should have different outcome in terms of model change and dirty state
Product: [Modeling] Graphiti Reporter: Henrik Rentz-Reichert <hrr>
Component: CoreAssignee: Michael Wenz <michael.wenz>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: michael.wenz, tim.kaiser
Version: 0.8.0Flags: michael.wenz: indigo+
Target Milestone: 0.8.0   
Hardware: All   
OS: All   
Whiteboard: Indigo RC1 theme_bugs

Description Henrik Rentz-Reichert CLA 2011-03-22 01:59:43 EDT 
Currently (as of Graphiti 0.8.0) hasDoneChanges() is used to determine whether the recorded command is put on top of the command stack or not. In the first case the editor state will change to dirty.

I see actually three cases which I would like to distinguish
(1) the feature has done no model changes and the editor should stay clean
(2) the feature has done model changes and the editor nevertheless should stay clean (e.g. I temporarily changed a color for highlighting)
(3) the feature has done model changes but I want the changes to be rolled back (e.g. a custom feature opened a property dialog which was canceled but actually did changes using data binding)

For the first two cases the hasDoneChanges() mechanism is just fine.
For (3) I have no simple solution except undoing the changes performed in the dialog. But this is tedious and it would be much easier if I could use the possibility to roll back the changes using the current transaction.
If I could throw an InterruptedException this possibly would do the job (I can't judge whether this would be a proper way at all). But then the execute() method would have to declare this exception.
Another possibility would be a second method
boolean rollbackChanges()
declared in the IFeature which by default is true and is called if hasDoneChanges() is false but the RecordingCommand contains changes. If rollbackChanges() returns true the changes are rolled back and the editor stays clean.
Comment 1 Michael Wenz CLA 2011-05-13 09:16:12 EDT 
In order to achieve 3) features must indicate cancellation via throwing a runtime exception (EMF uses org.eclipse.core.runtime.OperationCancelledException for this case). Through the hierarchy of the EMF/GEF commands and command stacks this exception was caught and not re-thrown, leading to this behavior.
Now when a feature throws an OperationCancelledException it reaches the outmost EMF command correctly and triggers a rollback of the complete operation.
Note: any other RuntimeException will have the same effect, but it will lead to an error entry in the Eclipse error log.

Checked-in to head.
Comment 2 Michael Wenz CLA 2011-06-24 08:41:59 EDT 
Part of Graphiti Indigo 0.8.0