|Re: StrictCompoundCommand and TransactionalEditingDomain [message #1403580 is a reply to message #1403472]
||Thu, 24 July 2014 13:42
|| Christian Damus
Registered: July 2009
The principle on which the StrictCompoundCommand works isn't compatible
with the transactional editing domain, as you have observed. However,
you may be able to create your own variant (say,
TransactionalStrictCompoundCommand) that does what the
StrictCompoundCommand does, only in a transaction. I haven't tried
this, so I can't promise that you can make it work.
To test whether it is executable, the strict compound executes its
children and then undoes them. I call this the "trial". Just wrap
that up in a transaction and you should be OK. You'll need the
InternalTransactionalEditingDomain API to start a transaction in which
context to execute the compound's commands. Probably applying the
Transaction.OPTION_NO_VALIDATION to it would be useful both to save the
cost of running validation and to avoid any roll-back of the
transaction if you commit it. Also, the
Transaction.OPTION_NO_NOTIFICATIONS would ensure that listeners don't
hear about changes made and undone by the trial.
That said, I'm not sure how you should close this trial transaction:
your compound could do what StrictCompoundCommand does and undo all of
the children that were executed, in which case you could presumably
just commit the transaction because it should have no effect (and there
won't be any notifications, thanks to that option). Or, you might roll
it back just to be sure. If committing the transaction works, then you
might also use the Transaction.OPTION_NO_UNDO to avoid recording undo
information for roll-back. But, if your compound has any
RecordingCommands as children, they won't be able to undo because they
depend on the transaction recording the changes, so that wouldn't work.
Hmm, now that I mention it, I'm not sure how undoing RecordingCommands
would interact with roll-back of the trial transaction. You may just
have to commit it, after all, and be sure not to use the OPTION_NO_UNDO.
Whew, you're going to have a lot of JUnit test cases on your hands.
When it's all done, it would make a splendid contribution to the EMF
Transaction project! :-D
On 2014-07-24 00:56:05 +0000, Alain Picard said:
> For many years we have extended the StrictCompoundCommand to create our
> own. Now we are switching some of those instances to operate with a
> transactional editing domain which results in errors as well documented
> in bugs like 207663.
> What I see there are fixes on the edges, but not to the prepare()
> method of StrictCompoundCommand that does invoke execute outside of a
> transaction, or delegating to the editing domain command stack.
> What is the plan with this?
Powered by FUDForum
. Page generated in 0.02071 seconds