Home » Modeling » EMF » How to persist (serialize) the CommandStack (undo-stack)
| How to persist (serialize) the CommandStack (undo-stack) [message #824321] |
Mon, 19 March 2012 14:28  |
Eclipse User |
|
|
|
Hi group,
I'm trying to save (and restore) the CommandStack, to that the user can
undo/redo the next time he uses my application. What is the best way to
implement this?
The goal is that the user can save his EMF model (and CommandStack),
close our application, and then later open our application and load the
EMF-model (and CommandStack), and then be able to undo operations done
in the last session.
I have searched the newsgroups and the web, without finding much direct
help.
In the thread "Persist command stack: PersistentCommandStack /
AdapterFactoryMappingDomain" Tobias Buhr mentions
PersistentCommandStack, but I can't find any plugin named
org.eclipse.emf.mapping (which contains the class
"org.eclipse.emf.mapping.command.PersistentCommandStack"). Has this
plugin been merged with another project/plugin?
Using ChangeRecorder (as Ed Merks suggests in the above mentioned
thread, as well as others) seems like a difficult approach when my goal
is to restore a CommandStack, and not "just" to be able to play back the
changes.
I am using Eclipse 3.7, and will be upgrading to 4.2 in near future.
I have started testing some code around the idea of (at the time the
user saves his EMF model) converting the CommandStack to (my
custom-created) ECommandStack containg ECommand's in various variants
(such as ESetCommand), and I guess I could succeed with this, but it
seems like much work to account for all possible Commands and variants
of the commands.
If anyone have any ideas or pointers, it would be greatly appreciated.
If there are others that are interested in the same functionality, I
will consider trying to create my implementation in such a way that it
can be contributed back to the community.
-Eirik
|
|
|
| Re: How to persist (serialize) the CommandStack (undo-stack) [message #824342 is a reply to message #824321] |
Mon, 19 March 2012 15:00  |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Eirik,
Comments below.
On 19/03/2012 3:28 PM, Eirik Wahl wrote:
> Hi group,
>
> I'm trying to save (and restore) the CommandStack, to that the user
> can undo/redo the next time he uses my application. What is the best
> way to implement this?
It's not designed for that purpose...
>
> The goal is that the user can save his EMF model (and CommandStack),
> close our application, and then later open our application and load
> the EMF-model (and CommandStack), and then be able to undo operations
> done in the last session.
It's by no means a trivial thing to implement...
>
> I have searched the newsgroups and the web, without finding much
> direct help.
>
> In the thread "Persist command stack: PersistentCommandStack /
> AdapterFactoryMappingDomain" Tobias Buhr mentions
> PersistentCommandStack, but I can't find any plugin named
> org.eclipse.emf.mapping (which contains the class
> "org.eclipse.emf.mapping.command.PersistentCommandStack"). Has this
> plugin been merged with another project/plugin?
The idea there was that we persisted the CommandParameters used to
create the command, but that assumes you're reading in the old version
of the model and wanting to play things forward to the final state,
which itself wasn't saved.
>
> Using ChangeRecorder (as Ed Merks suggests in the above mentioned
> thread, as well as others) seems like a difficult approach when my
> goal is to restore a CommandStack, and not "just" to be able to play
> back the changes.
>
> I am using Eclipse 3.7, and will be upgrading to 4.2 in near future.
>
> I have started testing some code around the idea of (at the time the
> user saves his EMF model) converting the CommandStack to (my
> custom-created) ECommandStack containg ECommand's in various variants
> (such as ESetCommand), and I guess I could succeed with this, but it
> seems like much work to account for all possible Commands and variants
> of the commands.
Yes, it's much work.
>
> If anyone have any ideas or pointers, it would be greatly appreciated.
> If there are others that are interested in the same functionality, I
> will consider trying to create my implementation in such a way that it
> can be contributed back to the community.
It seems like a lot of work. I don't think I recall any other editor
supporting something like this, so it's not something users generally
expect to have supported... You'd have to persist the undo stack
somewhere and there' no guarantee that the model isn't change in some
other way..
>
> -Eirik
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: How to persist (serialize) the CommandStack (undo-stack) [message #824951 is a reply to message #824910] |
Tue, 20 March 2012 09:24 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Eirik,
I think one of the trickier features (very tricky) is that you have to
create commands that are in a state as if they've already been executed
so undo can be called on them; normally prepare is called and then
execute, which gets things into the right state for calling undo. For
example, a remove command needs to record at which position the object
needs to be added back... At least we don't make a habit of making
things private, so it's not impossible, but I imagine you'll have to
subclass all command implementation classes to achieve your goal, i.e,
to get at state for which there isn't API and which can only be set via
protected access. Definitely it's an uphill struggle.
On 20/03/2012 9:19 AM, Eirik F. Wahl wrote:
> Ed,
>
> Thank you very much for your valuable feedback!
>
> You're right about this being an unusual feature to have, but we would
> like to have a go anyway. I guess, now that I know that this
> functionality does not exist yet, it is actually easier to (be
> motivated to) go ahead and try myself.
> Maybe I will be able to thank you in person next week at EclipseCon. :-)
>
> -Eirik
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: How to persist (serialize) the CommandStack (undo-stack) [message #825093 is a reply to message #824951] |
Tue, 20 March 2012 13:05 |
Eirik F. Wahl
Messages: 2
Registered: March 2012 |
Junior Member |
|
|
Thanks again.
A colleague and I have now looked over our application, and looked at some of the Command-implementations from EMF, and we think we should be able to do the task in less than a week, which is an acceptable budget for our project. This is, however, because we will limit the scope to only those Commands actually used in our product, and not all 15-ish Command types in EMF. Still, I read your "warning" loud and clear, so I hope we are not too naive...
As you point out; At least the different Commands can be sub-classed and have the state in protected fields, so we can create new instances of them without calling createCommand(...). (createCommand(...) is dependent on an EditingDomain-state, owner-state and other states we don't have access to at the time of deserializing.)
During the last couple of days I have implemented a short/thin "spike" in the functionality, which supports saving an undo-stack containing only SetCommands on EString and EDouble attributes. It works OK, after having to subclass BasicCommandStack to be able to set the (newly restored) Command list. We could of course feed the Command list via CommandStack as a parameter to the constructor for AdapterFactoryEditingDomain, but we won't be able to create (deserialize) the Commands without telling them what EditingDomand they are a part of... (Chicken-or-egg puzzle...)
Even if the Command-framework was not designed for serializing and deserializing, it seems to me to be very nicely designed and implemented, to be extendable and flexible. EMF was new to me 6 months ago, today I realize I have been missing out before I learned EMF. 
-Eirik
Ed Merks wrote on Tue, 20 March 2012 05:24Eirik,
I think one of the trickier features (very tricky) is that you have to
create commands that are in a state as if they've already been executed
so undo can be called on them; normally prepare is called and then
execute, which gets things into the right state for calling undo. For
example, a remove command needs to record at which position the object
needs to be added back... At least we don't make a habit of making
things private, so it's not impossible, but I imagine you'll have to
subclass all command implementation classes to achieve your goal, i.e,
to get at state for which there isn't API and which can only be set via
protected access. Definitely it's an uphill struggle.
On 20/03/2012 9:19 AM, Eirik F. Wahl wrote:
> Ed,
>
> Thank you very much for your valuable feedback!
>
> You're right about this being an unusual feature to have, but we would
> like to have a go anyway. I guess, now that I know that this
> functionality does not exist yet, it is actually easier to (be
> motivated to) go ahead and try myself.
> Maybe I will be able to thank you in person next week at EclipseCon.
>
> -Eirik
|
|
|
Goto Forum:
Current Time: Fri Apr 26 09:24:48 GMT 2024
Powered by FUDForum. Page generated in 0.03799 seconds |
] 
Search
Help
Register
Login
Home
