OpenEditPolicy, undo for raw EMF operations [message #643567] |
Tue, 07 December 2010 13:24 |
Eclipse User |
|
|
|
Originally posted by: marius.groeger.googlemail.com
Hi,
I have an OpenEditPolicy which openens an edit dialog. In this dialog I
can directly manipulate an EList<> of entities for which there is no
corresponding GMF editor. This editor is using EObject.eSet() methods to
manipulate the entities. Is this an error? Should I use an editing domain?
Secondly, and perhaps related: if I press 'Cancel' on the dialog, all
changes should be undone. What is the best way to do this? Make a deep
copy of the EList<> and work on that? There can be many changes, and I'm
not sure if I should create individual undoable commands for each change.
Thanks!
Marius
|
|
|
Re: OpenEditPolicy, undo for raw EMF operations [message #643671 is a reply to message #643567] |
Tue, 07 December 2010 19:04 |
Michael Golubev Messages: 383 Registered: July 2009 |
Senior Member |
|
|
Hello,
I am wondering why you don't get exceptions "XXX modified outside transaction" on your changes, because you should not be allowed to do modifications directly.
What about the cancel, I don't know any solution other than
- either making the changes with the separate set of cloned EObjects,
- or describing the input collected from the user in some kind of descriptors
Both cases are clearly similar (just using the same or different kind of objects to collect the data), and in both cases you are expected to push the collected info to actual model inside single TransactionalCommand, after the dialog is finished with Apply / Ok.
If you find other working solution, I personally would be interested to know.
Regards,
Michael
|
|
|
Re: OpenEditPolicy, undo for raw EMF operations [message #643926 is a reply to message #643671] |
Wed, 08 December 2010 16:58 |
Eclipse User |
|
|
|
Originally posted by: marius.groeger.googlemail.com
On 07.12.2010 20:04, Michael Golubev wrote:
> Hello,
> I am wondering why you don't get exceptions "XXX modified outside
> transaction" on your changes, because you should not be allowed to do
> modifications directly. :)
> What about the cancel, I don't know any solution other than - either
> making the changes with the separate set of cloned EObjects, - or
> describing the input collected from the user in some kind of descriptors
>
> Both cases are clearly similar (just using the same or different kind of
> objects to collect the data), and in both cases you are expected to push
> the collected info to actual model inside single TransactionalCommand,
> after the dialog is finished with Apply / Ok.
>
> If you find other working solution, I personally would be interested to
> know.
Well I did start by operating on a copied EList (using new
BasicEList<?>(EcoreUtil.copyAll(originalList)) this was really easy) and
then record all changes within an EMF CompoundCommand. Half way, though,
that felt quite awkward so I kept looking for alternatives. I have now
stumbled upon the ChangeRecorder, which looks indeed quite promising.
I'm not sure though how to exactly apply it.
For example, I could operate on the original list, recording all
modifications, and undo them when the user presses cancel. What is bad
about this approach is that other objects might be notified about these
model changes.
So it appears like I would still need to work on a copy, somehow, and
then use the ChangeRecorders ChangeDescription to replicate the
modifications on the real list once the user presses OK.
I'll let you know if it works out. If there are other suggestions I'm
still all ears...
Regards
Marius
|
|
|
Re: OpenEditPolicy, undo for raw EMF operations [message #644564 is a reply to message #643671] |
Mon, 13 December 2010 09:55 |
Eclipse User |
|
|
|
Originally posted by: marius.groeger.googlemail.com
On 07.12.2010 20:04, Michael Golubev wrote:
> Hello,
> I am wondering why you don't get exceptions "XXX modified outside
> transaction" on your changes, because you should not be allowed to do
> modifications directly. :)
Mystery solved - as my edit command inherited
AbstractTransactionalCommand, all manual changes were recorded.
> If you find other working solution, I personally would be interested to
> know.
I'm now doing this (reduced):
public class NetworkOpenDiagramEditPolicy extends OpenEditPolicy {
protected Command getOpenCommand(Request request) {
...
return new DialogEditCommand()
}
private static class DialogEditCommand extends
AbstractTransactionalCommand {
protected CommandResult doExecuteWithResult() {
recCmd = new RecordingCommand(domain) {
protected void doExecute() {
..open dialog
..save dialog result
commandStack.execute(recCmd);
if (dialog result == ok)
return ok;
else {
if recCmd.canUndo()
recCmd.undo()
}
}
public boolean canUndo() {
if (recCmd != null)
return recCmd.canUndo();
return false;
}
protected IStatus doUndo() {
recCmd.undo();
return Status.OK_STATUS;
}
public boolean canRedo() {
return false;
}
}
}
So if the dialog is cancelled, I undo the changes and forget about them.
Otherwise I return ok and allow undo, but no redo. Redo would open the
dialog again. I probably could work around this, but for now this is ok.
I have a feeling that this could be improved. For example, one downside
is that changes made in the dialog *are* done to model, and potential
listeners etc would be informed, and even perform other changes as a
consquence. But for now it works as I need it.
Regards
Marius
|
|
|
Powered by
FUDForum. Page generated in 0.05388 seconds