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

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

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