Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » using transactional editing domain with multiple command stacks?
using transactional editing domain with multiple command stacks? [message #1385811] Wed, 11 June 2014 11:11 Go to next message
m k is currently offline m kFriend
Messages: 6
Registered: June 2013
Junior Member
hello

we have a single ResourceSet containing a number of resources, and we want to use a transactional editing domain to provide undo / redo support based on transactions.
since we want undo / redo support on the level of resources (not the whole resource set), we figured we need a separate command stack for each resource.
since you can set the editing domain for a command stack (if you use TransactionalCommandStackImpl) we tried this, using multiple command stacks with one editing domain, and so far it seems to work.

nevertheless i wanted to check back with the experts (you Smile) if this is a good way to handle this, or if this should be done another way.

thanks in advance

m_k
Re: using transactional editing domain with multiple command stacks? [message #1385836 is a reply to message #1385811] Wed, 11 June 2014 14:15 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 844
Registered: July 2009
Senior Member
Hi, m_k,

My principal concern about this strategy is that cross-references
between resources can introduce logical dependencies between changes in
different resources. If you don't have cross-references between
resources, then that won't be a problem for you.

Your use case (or something like it) is the reason why the
WorkspaceEditingDomainFactory creates transactional editing domains
with a command-stack that delegates undo/redo history management to the
Eclipse Platform's IOperationHistory. This operation history
generalizes the concept of an undo history in a non-linear model based
on IUndoContexts; an undo context essentially selects a linear history
of operations out of the non-linear timeline. If you use this editing
domain, then your editor(s) can create an UndoActionHandler and
RedoActionHandler based on a ResourceUndoContext matching the resource
for which you want to provide the undo/redo history. The editing
domain automatically attaches ResourceUndoContexts to an operation for
each resource that is modified by that operation.

HTH,

Christian


On 2014-06-11 13:49:41 +0000, m k said:

> hello
>
> we have a single ResourceSet containing a number of resources, and we
> want to use a transactional editing domain to provide undo / redo
> support based on transactions.
> since we want undo / redo support on the level of resources (not the
> whole resource set), we figured we need a separate command stack for
> each resource. since you can set the editing domain for a command stack
> (if you use TransactionalCommandStackImpl) we tried this, using
> multiple command stacks with one editing domain, and so far it seems to
> work.
>
> nevertheless i wanted to check back with the experts (you :)) if this
> is a good way to handle this, or if this should be done another way.
>
> thanks in advance
>
> m_k
Re: using transactional editing domain with multiple command stacks? [message #1385852 is a reply to message #1385811] Wed, 11 June 2014 16:28 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 756
Registered: July 2009
Senior Member
Does each of the command stack have its own editing domain or do you mean that multiple command stacks use/share the same (only one instance of the) editing domain?

m k wrote on Wed, 11 June 2014 13:11
hello

we have a single ResourceSet containing a number of resources, and we want to use a transactional editing domain to provide undo / redo support based on transactions.
since we want undo / redo support on the level of resources (not the whole resource set), we figured we need a separate command stack for each resource.
since you can set the editing domain for a command stack (if you use TransactionalCommandStackImpl) we tried this, using multiple command stacks with one editing domain, and so far it seems to work.

nevertheless i wanted to check back with the experts (you Smile) if this is a good way to handle this, or if this should be done another way.

thanks in advance

m_k

Re: using transactional editing domain with multiple command stacks? [message #1385911 is a reply to message #1385836] Thu, 12 June 2014 08:42 Go to previous messageGo to next message
m k is currently offline m kFriend
Messages: 6
Registered: June 2013
Junior Member
hello

thank you for your answer. cross references do not exist, so luckily that's not an issue. however we now figured that using data binding in this scenario is most likely not going to work, so this solution is not preferable.

the problem i have is that i did not yet understand how to use the IUndoContexts here.

In an old implementation we manually applied IUndoContexts to commands but ended up with "hacking" the WorkspaceCommandStack to force it to keep the contexts, something we want to avoid now.
the problem was that, when i add a context to a command (by calling addContext), it is lost when the command is executed because the WorkspaceCommandStackImpl.doExecute() does not keep the contexts but only applies its default context.

when you say that the editing domain applies contexts automatically per resource, can you point me to the code that handles that, so i can take a look to maybe understand how it works?
also, if you know of any resources (for reading Smile) dealing with Undo / RedoActionHandlers, please let me know, google didn't turn up all that much so far.

cheers

m_k

@Erdal Karaca:
we can only have one editing domain, as we only have one resource set (at least that is how i understood it). the functionality we want to achieve is that we have a separate undo / redo history for each resource in our resource set. so we came up with the idea to use multiple command stacks, but i guess there should be a better way of doing this.

[Updated on: Thu, 12 June 2014 08:48]

Report message to a moderator

Re: using transactional editing domain with multiple command stacks? [message #1385949 is a reply to message #1385911] Thu, 12 June 2014 12:24 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 844
Registered: July 2009
Senior Member
Hi, m_k,

See some follow-up in-line, below.

HTH,

Christian


On 2014-06-12 08:42:30 +0000, m k said:

> hello
> thank you for your answer. cross references do not exist, so luckily
> that's not an issue. however we now figured that using data binding in
> this scenario is most likely not going to work, so this solution is not
> preferable.
>
> the problem i have is that i did not yet understand how to use the
> IUndoContexts here.
>
> In an old implementation we manually applied IUndoContexts to commands
> but ended up with "hacking" the WorkspaceCommandStack to force it to
> keep the contexts, something we want to avoid now.
> the problem was that, when i add a context to a command (by calling
> addContext), it is lost when the command is executed because the
> WorkspaceCommandStackImpl.doExecute() does not keep the contexts but
> only applies its default context.

Hmm ... that doesn't sound right. It should only *add* its default
context, not remove any that were added by other parties. Can you
debug to find out who is removing your context?


> when you say that the editing domain applies contexts automatically per
> resource, can you point me to the code that handles that, so i can take
> a look to maybe understand how it works?

Have a look at the WorkspaceCommandStackImpl::DomainListener class. It
computes the resources changed by an operation when it has finished
executing and adds the corresponding undo contexts to it.


> also, if you know of any resources (for reading :)) dealing with Undo /
> RedoActionHandlers, please let me know, google didn't turn up all that
> much so far.

Sorry, I start with Google, too. :-/


> cheers
>
> m_k
Re: using transactional editing domain with multiple command stacks? [message #1385956 is a reply to message #1385949] Thu, 12 June 2014 13:12 Go to previous messageGo to next message
m k is currently offline m kFriend
Messages: 6
Registered: June 2013
Junior Member
hello Christian

regarding the WorkspaceCommandStack.doExecute(), it actually creates a new EMFCommandOperation for each transactional command, dropping (ignoring) all contexts that are applied to the transactional command in the process, so they are not removed but just not added to the new operation. no idea if this is a bug or intended...

i'll look into that other code you mentioned, thanks for the help. Smile

cheers

m_k


Christian W. Damus wrote on Thu, 12 June 2014 08:24
Hi, m_k,

See some follow-up in-line, below.

HTH,

Christian


On 2014-06-12 08:42:30 +0000, m k said:

> hello
> thank you for your answer. cross references do not exist, so luckily
> that's not an issue. however we now figured that using data binding in
> this scenario is most likely not going to work, so this solution is not
> preferable.
>
> the problem i have is that i did not yet understand how to use the
> IUndoContexts here.
>
> In an old implementation we manually applied IUndoContexts to commands
> but ended up with "hacking" the WorkspaceCommandStack to force it to
> keep the contexts, something we want to avoid now.
> the problem was that, when i add a context to a command (by calling
> addContext), it is lost when the command is executed because the
> WorkspaceCommandStackImpl.doExecute() does not keep the contexts but
> only applies its default context.

Hmm ... that doesn't sound right. It should only *add* its default
context, not remove any that were added by other parties. Can you
debug to find out who is removing your context?


> when you say that the editing domain applies contexts automatically per
> resource, can you point me to the code that handles that, so i can take
> a look to maybe understand how it works?

Have a look at the WorkspaceCommandStackImpl::DomainListener class. It
computes the resources changed by an operation when it has finished
executing and adds the corresponding undo contexts to it.


> also, if you know of any resources (for reading Smile) dealing with Undo /
> RedoActionHandlers, please let me know, google didn't turn up all that
> much so far.

Sorry, I start with Google, too. :-/


> cheers
>
> m_k

Re: using transactional editing domain with multiple command stacks? [message #1385972 is a reply to message #1385956] Thu, 12 June 2014 14:22 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 844
Registered: July 2009
Senior Member
Oh, I see. Right, you're executing EMF Commands on the stack, of course.

But, Commands don't have undo contexts, only IUndoableOperations do.
So where should the stack find the contexts that it would transfer to
the EMFCommandOperation? There could be a useful enhancement hear
waiting for a contribution ... :-)

Note that you can execute operations on the history directly instead of
executing commands on the stack, but of course *that* won't work with
data bindings because the EMF databindings (understandably) only know
about CommandStacks.

cW


On 2014-06-12 13:12:25 +0000, m k said:

> hello Christian
>
> regarding the WorkspaceCommandStack.doExecute(), it actually creates a
> new EMFCommandOperation for each transactional command, dropping
> (ignoring) all contexts that are applied to the transactional command
> in the process, so they are not removed but just not added to the new
> operation. no idea if this is a bug or intended...
>
> i'll look into that other code you mentioned, thanks for the help. :)
>
> cheers
>
> m_k
>
>
> Christian W. Damus wrote on Thu, 12 June 2014 08:24
>> Hi, m_k,
>>
>> See some follow-up in-line, below.
>>
>> HTH,
>>
>> Christian
>>
>>
>> On 2014-06-12 08:42:30 +0000, m k said:
>>
>>> hello
>>> thank you for your answer. cross references do not exist, so luckily
>>> that's not an issue. however we now figured that using data binding in
>>> this scenario is most likely not going to work, so this solution is not
>>> preferable.
>>>
>>> the problem i have is that i did not yet understand how to use the
>>> IUndoContexts here.
>>>
>>> In an old implementation we manually applied IUndoContexts to commands
>>> but ended up with "hacking" the WorkspaceCommandStack to force it to
>>> keep the contexts, something we want to avoid now.
>>> the problem was that, when i add a context to a command (by calling
>>> addContext), it is lost when the command is executed because the
>>> WorkspaceCommandStackImpl.doExecute() does not keep the contexts but
>>> only applies its default context.
>>
>> Hmm ... that doesn't sound right. It should only *add* its default
>> context, not remove any that were added by other parties. Can you
>> debug to find out who is removing your context?
>>
>>
>>> when you say that the editing domain applies contexts automatically per
>>> resource, can you point me to the code that handles that, so i can take
>>> a look to maybe understand how it works?
>>
>> Have a look at the WorkspaceCommandStackImpl::DomainListener class. It
>> computes the resources changed by an operation when it has finished
>> executing and adds the corresponding undo contexts to it.
>>
>>
>>> also, if you know of any resources (for reading :)) dealing with Undo /
>>> RedoActionHandlers, please let me know, google didn't turn up all that
>>> much so far.
>>
>> Sorry, I start with Google, too. :-/
>>
>>
>>> cheers
>>>
>>> m_k
Re: using transactional editing domain with multiple command stacks? [message #1385979 is a reply to message #1385972] Thu, 12 June 2014 15:17 Go to previous message
m k is currently offline m kFriend
Messages: 6
Registered: June 2013
Junior Member
lol, i was just going to answer that you can add undo contexts to commands, but then i realized that we added this feature as well in our old implementation... dang! Smile

while the old impl. does work without problems i would still like to know if there's a proper way of doing this... i'll update if i find a solution.

cheers

m_k

Christian W. Damus wrote on Thu, 12 June 2014 10:22
Oh, I see. Right, you're executing EMF Commands on the stack, of course.

But, Commands don't have undo contexts, only IUndoableOperations do.
So where should the stack find the contexts that it would transfer to
the EMFCommandOperation? There could be a useful enhancement hear
waiting for a contribution ... Smile

Note that you can execute operations on the history directly instead of
executing commands on the stack, but of course *that* won't work with
data bindings because the EMF databindings (understandably) only know
about CommandStacks.

cW


Previous Topic:Rules for XMI serialization
Next Topic:[CDO] Advice on best approach to replacing model content
Goto Forum:
  


Current Time: Thu Dec 18 08:34:30 GMT 2014

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

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