EMF based Undo/Redo [message #520813] |
Mon, 15 March 2010 13:12 |
Jan Messages: 9 Registered: March 2010 |
Junior Member |
|
|
Hi,
We have an EMF based RCP application. From our data model we generate code.Our SWT widgets are connected with the EMF model, so changes in the model are automatically set in the Frontend.
We don't use an editor in our application, we only use views.
Now we wants to implement an Undo/Redo mechanism.
The first thing I have researched is using the ChangeRecorder. This seems to be very cool, and easy in use, but it seems to be only usable for transactions, cause it doesn't log all changes, you only have the start value and the latest value, but the values between start and end doesn't been logged.
Is it possible to adapt the ChangeRecorder to do some Undo/Redo functionality?
The second possibility seems to be much more complicated, to use some commands and a stack with Undo/Redo possibility. It seems also that you need an Editor what we don't have. Anymore it seems to be an Eclipse functionality and the use with EMF is not so easy, but it could be that I don't understand it full.
Which way is the preferable way?
Which way should we go nad what is possible?
Greetings
Jan
|
|
|
Re: EMF based Undo/Redo [message #520820 is a reply to message #520813] |
Mon, 15 March 2010 13:34 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
Jan,
Comments below.
Jan wrote:
> Hi,
>
> We have an EMF based RCP application. From our data model we generate
> code.Our SWT widgets are connected with the EMF model, so changes in
> the model are automatically set in the Frontend.
>
> We don't use an editor in our application, we only use views.
> Now we wants to implement an Undo/Redo mechanism.
>
> The first thing I have researched is using the ChangeRecorder. This
> seems to be very cool, and easy in use, but it seems to be only usable
> for transactions, cause it doesn't log all changes, you only have the
> start value and the latest value, but the values between start and end
> doesn't been logged.
Why would that matter?
>
> Is it possible to adapt the ChangeRecorder to do some Undo/Redo
> functionality?
ChangeCommand shows how to do that.
>
> The second possibility seems to be much more complicated, to use some
> commands and a stack with Undo/Redo possibility.
You need a stack to support undo/redo.
> It seems also that you need an Editor what we don't have.
No, an editing domain is sufficient.
> Anymore it seems to be an Eclipse functionality and the use with EMF
> is not so easy, but it could be that I don't understand it full.
>
>
> Which way is the preferable way?
> Which way should we go nad what is possible?
I think you should use an AdapterFactoryEditingDomain for creating and
executing commands just like what's in the editor.
>
> Greetings Jan
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Re: EMF based Undo/Redo [message #521085 is a reply to message #521078] |
Tue, 16 March 2010 12:40 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
Jan,
What's the difference between "every model change" verses "a
transaction"? It actually matters that wen a value is changed from x to
y and then to z it must change back to y and only then to x? In that
case, you should be using finer grained composed commands.
Jan wrote:
> Hi Ed,
>
> thanks for your help. Currently I try to develop a small
> test-application with an AdapterFactoryEditingDomain.
> One remark:
>
>>> The first thing I have researched is using the ChangeRecorder. This
>>> seems to be very cool, and easy in use, but it seems to be only usable
>>> for transactions, cause it doesn't log all changes, you only have the
>>> start value and the latest value, but the values between start and end
>>> doesn't been logged.
>> Why would that matter?
>
> It matters, cause with Undo/Redo I want to step back every model
> change and not only a transaction. But I think the command stack will
> do this.
>
> Greetings
> Jan
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02889 seconds