Eclipse Community Forums: EMF » Transaction OPTIONS_NO

Help

Home

Home » Modeling » EMF » Transaction OPTIONS_NO_TRIGGERS

Show: Today's Messages :: Show Polls :: Message Navigator

Transaction OPTIONS_NO_TRIGGERS [message #420278]

Tue, 24 June 2008 18:28

Alan

Messages: 44
Registered: July 2009

Member

Hello,

I am having an issue with a ResourceSetListener.
I have a command that changes the name of an object.
This command is caught by the transactionAboutToCommit method and so works
ok.
However on an undo precommit is not called due to the OPTIONS_NO_TRIGGERS
being set to true.
I am not sure why this is.

The situation is a little strange in that the command that gets undone is
not the one that made the change in the first place (it would take me too
long to explain, trust me :-)
so maybe this has something to do with it.

I have even set my own Options map on creating the transaction
(AbstractTransactionalCommand and AbstractEMFCommand both tried ) but to no
avail .

Anyone got any ideas ?

thanks,

Report message to a moderator

Re: Transaction OPTIONS_NO_TRIGGERS [message #420285 is a reply to message #420278]

Tue, 24 June 2008 20:41

Eclipse User

Originally posted by: cdamus.zeligsoft.com

--=-zdmniaA09HTKbI7DsNDo
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Alan,

An undo or redo transaction assumes that any changes that would be
triggered by it will be undone/redone by the trigger commands originally
contributed during the execution of the command that triggered them (the
transactional command stack actually composes the original command with
all of its triggers behind the scenes). This is the benefit of
encapsulating triggers as commands in the original execute transaction.

It sounds like a violation of the basic command-stack contract to be
switching commands in this way, so that undo doesn't undo the original
command.

The options that you would set on executing a command have no bearing on
the options used by the command-stack when undoing or redoing. These
options are determined by the
InternalTransactionalEditingDomain::getUndoRedoOptions() method. If you
own the editing domain and you know that you won't break any other
applications that might be using it, you could try customizing these
options when you construct your editing domain.

HTH,

Christian

On Tue, 2008-06-24 at 19:28 +0100, Alan wrote:

> Hello,
>
> I am having an issue with a ResourceSetListener.
> I have a command that changes the name of an object.
> This command is caught by the transactionAboutToCommit method and so works
> ok.
> However on an undo precommit is not called due to the OPTIONS_NO_TRIGGERS
> being set to true.
> I am not sure why this is.
>
> The situation is a little strange in that the command that gets undone is
> not the one that made the change in the first place (it would take me too
> long to explain, trust me :-)
> so maybe this has something to do with it.
>
> I have even set my own Options map on creating the transaction
> (AbstractTransactionalCommand and AbstractEMFCommand both tried ) but to no
> avail .
>
> Anyone got any ideas ?
>
> thanks,
>
>

--=-zdmniaA09HTKbI7DsNDo
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Alan, 
 
An undo or redo transaction assumes that any changes that would be triggered by it will be undone/redone by the trigger commands originally contributed during the execution of the command that triggered them (the transactional command stack actually composes the original command with all of its triggers behind the scenes).  This is the benefit of encapsulating triggers as commands in the original execute transaction. 
 
It sounds like a violation of the basic command-stack contract to be switching commands in this way, so that undo doesn't undo the original command. 
 
The options that you would set on executing a command have no bearing on the options used by the command-stack when undoing or redoing.  These options are determined by the InternalTransactionalEditingDomain::getUndoRedoOptions() method.  If you own the editing domain and you know that you won't break any other applications that might be using it, you could try customizing these options when you construct your editing domain. 
 
HTH, 
 
Christian 
 
 
On Tue, 2008-06-24 at 19:28 +0100, Alan wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hello,

I am having an issue with a ResourceSetListener.
I have a command that changes the name of an object.
This command is caught by the transactionAboutToCommit method and so works 
ok.
However on an undo precommit is not called due to the OPTIONS_NO_TRIGGERS 
being set to true.
I am not sure why this is.

The situation is a little strange in that the command that gets undone is 
not the one that made the change in the first place (it would take me too 
long to explain, trust me :-)
so maybe this has something to do with it.

I have even set my own Options map on creating the transaction 
(AbstractTransactionalCommand and AbstractEMFCommand both tried ) but to no 
avail .

Anyone got any ideas ?

thanks, 

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

--=-zdmniaA09HTKbI7DsNDo--

Report message to a moderator

Re: Transaction OPTIONS_NO_TRIGGERS [message #420636 is a reply to message #420285]

Thu, 26 June 2008 14:36

Alan

Messages: 44
Registered: July 2009

Member

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C8D7A2.63F1E490
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Christian,

Thanks for the reply. I started down the road of creasting a =
TransactionalEditngDomainImpl and overridding getUndoRedoOptions but as =
it turns out there was a much simpler solution to the problem which has =
nothing to do with transactions etc

Thanks anyway as it was informative to work through this stuff :-)

thanks,
Alan.
"Christian W. Damus" <cdamus@zeligsoft.com> wrote in message =
news:1214340080.6347.5.camel@cwdlappy...
Hi, Alan,

An undo or redo transaction assumes that any changes that would be =
triggered by it will be undone/redone by the trigger commands originally =
contributed during the execution of the command that triggered them (the =
transactional command stack actually composes the original command with =
all of its triggers behind the scenes). This is the benefit of =
encapsulating triggers as commands in the original execute transaction.

It sounds like a violation of the basic command-stack contract to be =
switching commands in this way, so that undo doesn't undo the original =
command.

The options that you would set on executing a command have no bearing =
on the options used by the command-stack when undoing or redoing. These =
options are determined by the =
InternalTransactionalEditingDomain::getUndoRedoOptions() method. If you =
own the editing domain and you know that you won't break any other =
applications that might be using it, you could try customizing these =
options when you construct your editing domain.

HTH,

Christian

On Tue, 2008-06-24 at 19:28 +0100, Alan wrote:=20
Hello,

I am having an issue with a ResourceSetListener.
I have a command that changes the name of an object.
This command is caught by the transactionAboutToCommit method and so =
works=20
ok.
However on an undo precommit is not called due to the =
OPTIONS_NO_TRIGGERS=20
being set to true.
I am not sure why this is.

The situation is a little strange in that the command that gets undone =
is=20
not the one that made the change in the first place (it would take me =
too=20
long to explain, trust me :-)
so maybe this has something to do with it.

I have even set my own Options map on creating the transaction=20
(AbstractTransactionalCommand and AbstractEMFCommand both tried ) but to =
no=20
avail .

Anyone got any ideas ?

thanks,=20

------=_NextPart_000_000B_01C8D7A2.63F1E490
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; CHARSET=3DUTF-8">
<META content=3D"MSHTML 6.00.6000.16640" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Christian,</DIV>
<DIV> </DIV>
<DIV>Thanks for the reply. I started down =
the road of=20
creasting a TransactionalEditngDomainImpl and overridding =
getUndoRedoOptions but=20
as it turns out there was a much simpler solution to the problem which =
has=20
nothing to do with transactions etc</DIV>
<DIV> </DIV>
<DIV>Thanks anyway as it was informative to =
work through=20
this stuff :-)</DIV>
<DIV> </DIV>
<DIV>thanks,</DIV>
<DIV>Alan.</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Christian W. Damus" <<A=20
href=3D"mailto:cdamus@zeligsoft.com">cdamus@zeligsoft.com</A>> =
wrote in=20
message <A=20
=
href=3D"news:1214340080.6347.5.camel@cwdlappy">news:1214340080.6347.5.cam=
el@cwdlappy</A>...</DIV>Hi,=20
Alan, An undo or redo transaction assumes that any changes that =
would=20
be triggered by it will be undone/redone by the trigger commands =
originally=20
contributed during the execution of the command that triggered them =
(the=20
transactional command stack actually composes the original command =
with all of=20
its triggers behind the scenes).  This is the benefit of =
encapsulating=20
triggers as commands in the original execute transaction. It =
sounds=20
like a violation of the basic command-stack contract to be switching =
commands=20
in this way, so that undo doesn't undo the original =
command. The=20
options that you would set on executing a command have no bearing on =
the=20
options used by the command-stack when undoing or redoing.  These =
options=20
are determined by the =
InternalTransactionalEditingDomain::getUndoRedoOptions()=20
method.  If you own the editing domain and you know that you =
won't break=20
any other applications that might be using it, you could try =
customizing these=20
options when you construct your editing=20
domain. HTH, Christian On Tue, 2008-06-24 at =
19:28=20
+0100, Alan wrote:=20
<BLOCKQUOTE TYPE=3D"CITE"><PRE>Hello,

I am having an issue with a =
ResourceSetListener.
I have a command that changes the name of an =
object.
This command is caught by the =
transactionAboutToCommit method and so works 
ok.
However on an undo precommit is not called due to =
the OPTIONS_NO_TRIGGERS 
being set to true.
I am not sure why this is.

The situation is a little strange in that the =
command that gets undone is 
not the one that made the change in the first =
place (it would take me too 
long to explain, trust me :-)
so maybe this has something to do with it.

I have even set my own Options map on creating the =
transaction 
(AbstractTransactionalCommand and =
AbstractEMFCommand both tried ) but to no 
avail .

Anyone got any ideas ?

thanks, 

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

------=_NextPart_000_000B_01C8D7A2.63F1E490--

Report message to a moderator

Re: Transaction OPTIONS_NO_TRIGGERS [message #420640 is a reply to message #420636]

Fri, 04 July 2008 17:01

Eclipse User

Originally posted by: cdamus.zeligsoft.com

--=-wnFDcl4ecdsSaxSfZDJk
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sure, no problem! I'm glad you got it working.

Just FYI, you wouldn't actually have to create your own editing domain
implementation. I think you can set the undo/redo options in a custom
TransactionalEditingDomain.Factory.

Cheers,

Christian

On Thu, 2008-06-26 at 15:36 +0100, Alan wrote:

> =EF=BB=BF=20
>=20
> Christian,
> =20
> Thanks for the reply. I started down the road of creasting a
> TransactionalEditngDomainImpl and overridding getUndoRedoOptions but
> as it turns out there was a much simpler solution to the problem which
> has nothing to do with transactions etc
> =20
> Thanks anyway as it was informative to work through this stuff :-)
> =20
> thanks,
> Alan.

-----8<-----

--=-wnFDcl4ecdsSaxSfZDJk
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY BGCOLOR="#ffffff">
Sure, no problem!  I'm glad you got it working. 
 
Just FYI, you wouldn't actually have to create your own editing domain implementation.  I think you can set the undo/redo options in a custom TransactionalEditingDomain.Factory. 
 
Cheers, 
 
Christian 
 
 
On Thu, 2008-06-26 at 15:36 +0100, Alan wrote: 
<BLOCKQUOTE TYPE=CITE>
 
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
Christian,
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
 
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
Thanks for the reply. I started down the road of creasting a TransactionalEditngDomainImpl and overridding getUndoRedoOptions but as it turns out there was a much simpler solution to the problem which has nothing to do with transactions etc
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
 
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
Thanks anyway as it was informative to work through this stuff :-)
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
 
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
thanks,
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
Alan.
</BLOCKQUOTE>
<PRE>

</PRE>
-----8<-----
</BODY>
</HTML>

--=-wnFDcl4ecdsSaxSfZDJk--

Report message to a moderator

Previous Topic:	Mark an EAttribute as deprecated
Next Topic:	Notification for tree w/ Multiple Items per Object

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 26 11:47:58 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter