Hi Tristan
I'm not sure that anyone knows EMF Transaction very well. I used it
because it seemed to solve the diverse Command incompatibilities, and
to allow multiple views of Resources to synchronize across editors. It
places interesting games with eSet() to make sure that a remarkable
amount happens transparently, endeavouring to get the best of both
worlds.
I recommend reading the tutorials and only dismissing EMF Transaction
after forming a clear view as to how the same functionality should be
performed better and if so considering how an EMF Transaction 2 can
evolve.
I'm sure that you, like me a couple of years ago, just want to get past
this tedious Command problem to do something more interesting. However
if you don't address the problem clearly now, you and others will be
forever fighting the inadequacy of your partial solution.
Regards
Ed Willink
On 27/05/2010 10:13, Tristan FAURE wrote:
Hi all,
I don't really know the EMF Transaction Framework. But one of the
advantage of using the editing domain is that the eadapters installed
on editing domain are notified after commands execution.
Is it the same for IOperationHistory.execute ?
Regards
Tristan
Le 27/05/2010 10:35, Cedric Dumoulin a écrit :
Hi Ed,
Thanks for your feedback. I will study all of that, and try to
propose a solution for Papyrus asap.
Cedric
Ed Willink wrote:
Hi Cedric
This is a very painful area, that I sort of got to the bottom of for
the QVTd editor framework.
I think you need to go with IOperationHistory to stand any chance of
general consistency.
EMF Transaction provides an enhanced Command handling that IIRC uses
IOperationHistory.
You might care to check out org.eclipse.m2m2/org.eclipse.qvtd and look
for all IOperationHistory usage to see where I though I needed to
change things. Of course that was nearly two years ago and might not
have been the correct solution then let alone now.
When using IOperationHistory make sure you install the Platform
Examples which include a useful OperationHistory viewer. I send in a
few Bugzillas to projects that were not giving good Operation
descriptions.
That said, the entire EMF model synchronmisation issue deserves
revisiting. Xtext is not using any standard approach and we need Xtext
maintained models to be properly synchronized.
Regards
Ed Willink
On 25/05/2010 13:03, Cedric Dumoulin wrote:
Hi all,
I have opened a bug (314250) to try to clarify how Commands should be
executed in Papyrus.
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=314250)
Actually, commands seem to be executed using different mechanisms:
-
org.eclipse.emf.edit.domain.EditingDomain.getCommandStack().execute(...)
-
org.eclipse.core.commands.operations.IOperationHistory.execute(IUndoableOperation,
IProgressMonitor,
IAdaptable)
We need to propose a standard mechanism to be used in Papyrus.
Before that, we need to clarify what are the pro and cons of each
approach.
This should enable the undo/redo operations for all commands (bug
314252).
If you have any idea/clue/proposal, please comment it !
Cedric
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.819 / Virus Database: 271.1.1/2894 - Release Date: 05/24/10 19:26:00
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.819 / Virus Database: 271.1.1/2899 - Release Date: 05/27/10 07:25:00
|
