Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Provoke a rollback while executing a RemoveCommand
Provoke a rollback while executing a RemoveCommand [message #418523] Thu, 17 April 2008 15:48 Go to next message
Eclipse UserFriend
Originally posted by: bsu.bergauer.ch

Hello there,

When the RemoveCommand is invoked from my EMF editor, I need to
conditionally pop up a confirm dialog to ask the user for permission
(depending on if there exist non containment references or not). It is
important that this is checked when the RemoveCommand is actually executed,
not when it is created.

After overriding the createRemoveCommand() in the generated ItemProvider of
the containment object, I return an extended RemoveCommand doing this check
in the doExecute() method before calling super.doExecute().

However, as I found out, the only way to stop the CompoundCommand that is
executing the RemoveCommand and get it to roll back, if the user clicks
cancel in the confirm dialog, is to throw a RuntimeException (i.e
UnsupportedOperationException). The CompoundCommand catches the
RuntimeException and rolls back the command chain. Unforunately the
RuntimeException is also resulting in an error dialog which I do not want to
annoy the user with.

Does anyone have a good solution how to solve this problem?

Thanks in advance!
Bjoern Sundin
Re: Provoke a rollback while executing a RemoveCommand [message #418529 is a reply to message #418523] Thu, 17 April 2008 16:13 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020801010308000104080603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Bj


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Provoke a rollback while executing a RemoveCommand [message #418546 is a reply to message #418529] Fri, 18 April 2008 08:10 Go to previous message
Eclipse UserFriend
Originally posted by: bsu.bergauer.ch

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C8A13C.7D44CDF0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Ed and thanks for your fast reply!

Yes, this was a suitable handling of my problem, I had, however, some =
complications in getting to the BasicCommandStack in order to specialize =
it. My app is using two emf editors and one gmf diagram with a shared =
editing domain. As of now, the editing domain is initiated by the =
diagram plugin invoking =
GMFEditingDomainFactory.INSTANCE.createEditingDomain(). By also =
extending the GMFEditingDomainFactory though, this solution worked.

Thanks a lot!
Bjoern
"Ed Merks" <merks@ca.ibm.com> schrieb im Newsbeitrag =
news:fu7svq$99i$1@build.eclipse.org...
Bj=F6rn,

You could specialize the way the exception is handled in the =
BasicCommandStack:

/**
* Handles an exception thrown during command execution by loging =
it with the plugin.
*/
protected void handleError(Exception exception)=20
{
CommonPlugin.INSTANCE.log
(new WrappedException
=
(CommonPlugin.INSTANCE.getString("_UI_IgnoreException_exception "), =
exception).fillInStackTrace());
}


Bj=F6rn Sundin wrote:=20
Hello there,

When the RemoveCommand is invoked from my EMF editor, I need to
conditionally pop up a confirm dialog to ask the user for permission
(depending on if there exist non containment references or not). It is
important that this is checked when the RemoveCommand is actually =
executed,
not when it is created.

After overriding the createRemoveCommand() in the generated ItemProvider =
of
the containment object, I return an extended RemoveCommand doing this =
check
in the doExecute() method before calling super.doExecute().

However, as I found out, the only way to stop the CompoundCommand that =
is
executing the RemoveCommand and get it to roll back, if the user clicks
cancel in the confirm dialog, is to throw a RuntimeException (i.e
UnsupportedOperationException). The CompoundCommand catches the
RuntimeException and rolls back the command chain. Unforunately the
RuntimeException is also resulting in an error dialog which I do not =
want to
annoy the user with.

Does anyone have a good solution how to solve this problem?

Thanks in advance!
Bjoern Sundin


=20

------=_NextPart_000_000E_01C8A13C.7D44CDF0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2800.1528" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Ed and thanks for your fast =
reply!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Yes, this was&nbsp;a suitable handling =
of my=20
problem,&nbsp; I had, however, some complications in getting to the=20
BasicCommandStack in order to specialize it. My app is using two emf =
editors and=20
one gmf diagram with a shared editing domain. As of now,&nbsp;the =
editing domain=20
is initiated by the diagram plugin&nbsp;invoking=20
GMFEditingDomainFactory.INSTANCE.createEditingDomain(). By also =
extending the=20
GMFEditingDomainFactory though, this solution worked.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks a lot!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Bjoern</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" &lt;<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>&gt;=20
schrieb im Newsbeitrag <A=20
=
href=3D"news:fu7svq$99i$1@build.eclipse.org">news:fu7svq$99i$1@build.ecli=
pse.org</A>...</DIV>Bj=F6rn,<BR><BR>You=20
could specialize the way the exception is handled in the=20
BasicCommandStack:<BR>
<BLOCKQUOTE><SMALL>&nbsp; /**<BR>&nbsp;&nbsp; * Handles an exception =
thrown=20
during command execution by loging it with the =
plugin.<BR>&nbsp;&nbsp;=20
*/<BR>&nbsp; protected void handleError(Exception exception) =
<BR>&nbsp;=20
{<BR>&nbsp;&nbsp;&nbsp;=20
CommonPlugin.INSTANCE.log<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (new=20
WrappedException<BR> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; =

(CommonPlugin.INSTANCE.getString("_UI_IgnoreException_exception "),=20
exception).fillInStackTrace());<BR>&nbsp; =
}</SMALL><BR></BLOCKQUOTE><BR>Bj=F6rn=20
Sundin wrote:=20
<BLOCKQUOTE cite=3Dmid:fu7rga$ilf$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Hello there,

When the RemoveCommand is invoked from my EMF editor, I need to
conditionally pop up a confirm dialog to ask the user for permission
(depending on if there exist non containment references or not). It is
important that this is checked when the RemoveCommand is actually =
executed,
not when it is created.

After overriding the createRemoveCommand() in the generated ItemProvider =
of
the containment object, I return an extended RemoveCommand doing this =
check
in the doExecute() method before calling super.doExecute().

However, as I found out, the only way to stop the CompoundCommand that =
is
executing the RemoveCommand and get it to roll back, if the user clicks
cancel in the confirm dialog, is to throw a RuntimeException (i.e
UnsupportedOperationException). The CompoundCommand catches the
RuntimeException and rolls back the command chain. Unforunately the
RuntimeException is also resulting in an error dialog which I do not =
want to
annoy the user with.

Does anyone have a good solution how to solve this problem?

Thanks in advance!
Bjoern Sundin


</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000E_01C8A13C.7D44CDF0--
Previous Topic:issue with saving EMF Resources , HREF shoud refer to relative path instead of absolute
Next Topic:Xtext (4.3 beta) for EMF resources
Goto Forum:
  


Current Time: Thu Mar 28 16:07:17 GMT 2024

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

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

Back to the top