Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » GMF (Graphical Modeling Framework) » OpenEditPolicy, undo for raw EMF operations
OpenEditPolicy, undo for raw EMF operations [message #643567] Tue, 07 December 2010 13:24 Go to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Michael Golubev is currently offline Michael GolubevFriend
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. Smile

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 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous message
Eclipse UserFriend
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
Previous Topic:XML serialization in GMF
Next Topic:How to set target decoration of connectors
Goto Forum:
  


Current Time: Thu Mar 28 13:55:04 GMT 2024

Powered by FUDForum. Page generated in 0.01963 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top