|Help with Transactional Editing Domain and Modal Dialogs [message #1059098]
||Thu, 16 May 2013 16:50
| Jon Buck
Registered: July 2009
Really need some help with a problem I have been banging my head against for a couple of days now...
Basically my use case is one where I want to allow the user to edit some data contained within my model via a modal dialog(TitleAreaDialog) and as such then handle the cases where the user has made changes to the data but then chooses to cancel the dialog thereby requiring any changes to be undone...
Now I have previously been successfully able to achieve this effect using a standard Adapter Factory Editing Domain and a ChangeRecorder calling either endRecording() for OK and endRecording().applyAndReverse() for Cancel however the complication now is that I have to use a Transactional Editing Domain and this technique no longer works as I get an IllegalStateException: Cannot modify resource set without a write transaction..
I have looked into whether there is a Transactional equivalent which there seems to be albeit slightly different in creation however when I hit cancel it doesn't return a ChangeDescription so I get a NullPointerException...
My application is based on eclipse 3.6.2 with EMF 2.6.1 (Transaction 1.4.0)
So looking for some suggestions/examples as to how I might start looking into and implementing this requirement using a Transactional editing domain...
|Re: Help with Transactional Editing Domain and Modal Dialogs [message #1059514 is a reply to message #1059510]
||Mon, 20 May 2013 08:13
| Ed Merks
Registered: July 2009
On 20/05/2013 9:58 AM, Jon Buck wrote:
> Hi Ed,
> Thanks very much for your reply, answers to your comments below:
> What did you do for OK? Did you turn it into a command somehow and
> execute that so that the command stack state is valid?
> [JB] So to answer the question I should mention that the source object
> is being passed into the dialog and then I am using EMF Databinding to
> bind the ui controls to the model and I was under the impression that
> databinding is doing the right thing when making changes to the model..
That depends if you're using the EMFEditProperties, but if so, that will
execute commands for each change and you'd need to call undo enough
times on the command stack to deal with cancel...
> so for OK I just end the recording allowing the changes made within
> the dialog to remain...
> I don't know the transactional framework well, but it does support the
> notion of rollback when command execution fails, so my sense is that
> you need to do all this as part of executing a command and in the case
> of cancel, throw and exception that will cause a rollback.
> [JB] This sounds reasonable however where would it rollback to?
To the start of the command's execution...
> as I am using databinding every change in the UI controls invokes a
> change in the model so there could be n number of individual changes
> taking place as the user types a value in a text field, or makes a
> choice in a list etc.
Yes, but given that you've executed commands, I imagine you should be
undoing those so that the command stack has no trace of the canceled
> Somehow you need to be doing the changes as part of a command so that
> it either is properly recorded in an undoable way on the command stack
> or is rolled back...
> [JB] Yes completely agree and believe that I am doing that as I am
> making use of EMF DataBinding within the dialog, I have also double
> checked that the correct editing domain is being passed into the
> EMFEditProperties objects within the bindings...
Yes, it makes commands for you, but you'd need to undo those commands,
not simply change the model's state back with direct model changes...
So you might add a command stack listener that listens for how many
commands are executed from when the dialog is opened up to before cancel
is pressed and then call undo that number of times if cancel is pressed.
Powered by FUDForum
. Page generated in 0.02150 seconds