Home » Modeling » EMF » EMF command redo returns uncomplete Graphiti diagram
| EMF command redo returns uncomplete Graphiti diagram [message #1462571] |
Wed, 05 November 2014 18:28  |
 Laurent Le Moux
Messages: 184
Registered: September 2011 |
Senior Member |
|
|
Hi all,
I recently posted a topic in the Graphiti forum :
https://www.eclipse.org/forums/index.php/t/842301/
But, while investigating my problem, I started to think the explanation could be on the EMF side.
Graphiti diagrams are EMF models that I choose to store in CDO.
Starting from an empty diagram displayed as the following array by the debugger :
[null, [], [], null, [], [Color@OID70, Color@OID71], null, []]
I add an element to my diagram :
[[], [], [ContainerShape@oid1[NEW]], null, [], [Color@OID70, Color@OID71, Color@oid3[NEW], Color@oid4[NEW], Color@oid12[NEW]], [Font@oid13[NEW]], [PictogramLink@oid5[NEW], PictogramLink@oid14[NEW]]]
I can then perform an undo :
[[], [], [], null, [], [Color@OID70, Color@OID71], [], []]
But the redo fails as some elements are not added back to the diagram :
[[], [], [], null, [], [Color@OID70, Color@OID71, Color@oid17[NEW], Color@oid18[NEW], Color@oid19[NEW]], [], [PictogramLink@oid21[NEW], PictogramLink@oid24[NEW]]]
Colors and pictogram links have correctly been added back (with their new cdo IDs) but the container shape and the font objects are missing...
Graphiti undo and redo are based on the EMF command ones.
Following the EMF calling stack down to ChangeDescriptionImpl.applyAndReverse, objectChanges and objectsToAttach lists seem to contain all the expected objects.
But, after the call of FeatureChangeImpl.process, it seems that some objects are not added to objectsBeforeApply and objectsAfterApply. And they correspond to the missing ones after redo.
As the Graphiti tutorial works fine with redo, I guess the problem results from modifications I made to graphiti.ecore and / or graphiti.genmodel (see attached files).
In the ecore model, I added an DiagramMetaData class that is now referenced by the Diagram class.
In the genmodel, I made the modifications to become CDO compliant according to the corresponding CDO wiki.
I hope someone can tell me what is it I did wrong...
Kind regards,
Laurent
|
|
|
| Re: EMF command redo returns uncomplete Graphiti diagram [message #1464299 is a reply to message #1462571] |
Fri, 07 November 2014 11:55  |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Laurent,
Sorry, there are too many technologies involved that I can just answer
something like this looking at a *.ecore...
On 05/11/2014 7:28 PM, Laurent Le Moux wrote:
> Hi all,
>
> I recently posted a topic in the Graphiti forum :
> https://www.eclipse.org/forums/index.php/t/842301/
>
> But, while investigating my problem, I started to think the explanation could be on the EMF side.
> Graphiti diagrams are EMF models that I choose to store in CDO.
>
> Starting from an empty diagram displayed as the following array by the debugger :
>
> [null, [], [], null, [], [Color@OID70, Color@OID71], null, []]
>
>
> I add an element to my diagram :
>
> [[], [], [ContainerShape@oid1[NEW]], null, [], [Color@OID70, Color@OID71, Color@oid3[NEW], Color@oid4[NEW], Color@oid12[NEW]], [Font@oid13[NEW]], [PictogramLink@oid5[NEW], PictogramLink@oid14[NEW]]]
>
>
> I can then perform an undo :
>
> [[], [], [], null, [], [Color@OID70, Color@OID71], [], []]
>
>
> But the redo fails as some elements are not added back to the diagram :
>
> [[], [], [], null, [], [Color@OID70, Color@OID71, Color@oid17[NEW], Color@oid18[NEW], Color@oid19[NEW]], [], [PictogramLink@oid21[NEW], PictogramLink@oid24[NEW]]]
>
> Colors and pictogram links have correctly been added back (with their new cdo IDs) but the container shape and the font objects are missing...
>
> Graphiti undo and redo are based on the EMF command ones.
> Following the EMF calling stack down to ChangeDescriptionImpl.applyAndReverse, objectChanges and objectsToAttach lists seem to contain all the expected objects.
>
> But, after the call of FeatureChangeImpl.process, it seems that some objects are not added to objectsBeforeApply and objectsAfterApply. And they correspond to the missing ones after redo.
>
> As the Graphiti tutorial works fine with redo, I guess the problem results from modifications I made to graphiti.ecore and / or graphiti.genmodel (see attached files).
>
> In the ecore model, I added an DiagramMetaData class that is now referenced by the Diagram class.
> In the genmodel, I made the modifications to become CDO compliant according to the corresponding CDO wiki.
>
> I hope someone can tell me what is it I did wrong...
>
> Kind regards,
>
> Laurent
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| [CDO] Redo on CDO object returns an uncomplete Graphiti diagram [message #1464532 is a reply to message #1464299] |
Fri, 07 November 2014 17:12 |
Laurent Le Moux
Messages: 184
Registered: September 2011 |
Senior Member |
|
|
Hi Ed,
You're right... I followed the calling stack and - to make it short - the problem seems to be on CDO side. Is there a way to add the [CDO] prefix to my topic title ?
Adding a shape to my Graphiti diagram is ok. Undo is also Ok. But redo fails with a dirty but empty diagram.
So, I had a deeper look at the redo processing.
Redoing the add command basically leads to three major steps in the EMF (generic) execution :
- First add back the shape to the diagram.
- As the Graphiti ecore model defines an 'EOpposite' reference, an 'inverseAdd' is then executed which leads to the removal of the shape from the diagram.
- Finally, the diagram is set as the shape container again.
Each steps leads to a call of CDOStateMachine$WriteTransition.execute which takes care of updating the CDO objects 'diagram' and 'shape' accordingly.
Except for the last step...
Setting the diagram as the shape container leads to the call of CDOStateMachine$WriteNewTransition.execute which, in turn, calls CDOContainerFeatureDeltaImpl.applyTo.
And this method is apparently not updating the diagram to hold the shape reference as expected...
public Object applyTo(CDORevision revision)
{
InternalCDORevision internalRevision = (InternalCDORevision)revision;
internalRevision.setResourceID(newResourceID);
internalRevision.setContainerID(newContainerID);
internalRevision.setContainingFeatureID(newContainerFeatureID);
return null;
}
If I'm right, what would the workaround be ? Simply returning internalRevision in the debug mode is not working ?
Regards,
Laurent
[Updated on: Fri, 07 November 2014 17:14] Report message to a moderator |
|
|
| Re: [CDO] Redo on CDO object returns an uncomplete Graphiti diagram [message #1470344 is a reply to message #1464532] |
Wed, 12 November 2014 09:09 |
Esteban Dugueperoux
Messages: 472
Registered: July 2009 |
Senior Member |
|
|
Hi Laurent,
Which release of CDO do you use?
If you have the bug with the last one, could you write a JUnit test to
reproduce your issue?
Best Regards.
Le 07/11/2014 18:12, Laurent Le Moux a écrit :
> Hi Ed,
>
> You're right... I followed the calling stack and - to make it short -
> the problem seems to be on CDO side. That's the reason why I changed the
> topic title...
>
> Adding a shape to my Graphiti diagram is ok. Undo is also Ok. But redo
> fails with a dirty but empty diagram.
>
> So, I had a deeper look at the redo processing.
> Redoing the add command basically leads to three major steps in the EMF
> (generic) execution :
> - First add back the shape to the diagram.
> - As the Graphiti ecore model defines an 'EOpposite' reference, an
> 'inverseAdd' is then executed which leads to the removal of the shape
> from the diagram.
> - Finally, the diagram is set as the shape container again.
>
> Each steps leads to a call of CDOStateMachine$WriteTransition.execute
> which takes care of updating the CDO objects 'diagram' and 'shape'
> accordingly.
> Except for the last step...
>
> Setting the diagram as the shape container leads to the call of
> CDOStateMachine$WriteNewTransition.execute which, in turn, calls
> CDOContainerFeatureDeltaImpl.applyTo.
>
> And this method is apparently not updating the diagram to hold the shape
> reference as expected...
>
>
> public Object applyTo(CDORevision revision)
> {
> InternalCDORevision internalRevision = (InternalCDORevision)revision;
> internalRevision.setResourceID(newResourceID);
> internalRevision.setContainerID(newContainerID);
> internalRevision.setContainingFeatureID(newContainerFeatureID);
> return null;
> }
>
>
> If I'm right, what would the workaround be ? Simply returning
> internalRevision in the debug mode is not working ?
>
> Regards,
>
> Laurent
--
Esteban Dugueperoux - Obeo
Need professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
| | | | | |
| Re: [CDO] Redo on CDO object returns an uncomplete Graphiti diagram [message #1490918 is a reply to message #1489533] |
Fri, 28 November 2014 14:58 |
Laurent Le Moux
Messages: 184
Registered: September 2011 |
Senior Member |
|
|
Hi again,
I had a look at the feature change objects during undo and redo in both EObject and CDOObject "contexts" (still using the Graphiti tutorial example for test).
I noticed "small" differences like a null pointer instead of an empty array (as I already pointed out at the beginning of this topic).
But the following difference did really attract my attention :
In case of a succesful redo based on EObjects, the shape that is contained in my diagram with an EOpposite reference, has the following feature change object :
feature = container (ERef), value = diagram, new value = null and an empty list of changes.
Whereas, for a failing redo based on CDOObjects, the shape has the following change object :
feature = container, value = diagram, new value = diagram, list of changes = null...
I don't know whether this could be the cause of my problem.
In the debugger, I forced new value = null but redo is still failing... 
And I have difficulties to find out where this feature change instance has been created.
Any idea of what happens ?
Regards,
Laurent
|
|
| | |
Goto Forum:
Current Time: Fri Apr 19 00:59:55 GMT 2024
Powered by FUDForum. Page generated in 0.01973 seconds |
] 
Search
Help
Register
Login
Home
