Home » Modeling » EMF » Persist command stack: PersistentCommandStack / AdapterFactoryMappingDomain
| Persist command stack: PersistentCommandStack / AdapterFactoryMappingDomain [message #414467] |
Thu, 08 November 2007 12:05  |
Eclipse User |
|
|
|
Originally posted by: tobiasbuhr.gmx.de
Hi group,
when searching for a way to persist the (Basic)CommandStack, I found the
class org.eclipse.emf.mapping.command.PersistentCommandStack in the
org.eclipse.emf.mapping plugin.
Unfortunately, I neither find any documentiation nor a sample for it's
usage.
Can somebody help me out?
Furthermore I think, for it's invokation one needs to use the
AdapterFactoryMappingDomain instead of the common
AdapterFactoryEditingDomain - but how do I provide the neccessary
mappingDomainAdapterFactory for it's creation?
Thanks for your time,
Tobias
|
|
|
| Re: Persist command stack: PersistentCommandStack / AdapterFactoryMappingDomain [message #414470 is a reply to message #414467] |
Thu, 08 November 2007 12:47  |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Tobias,
Yes, this was specialized for use with the mapping framework were folks
wanted to use the actions they took as a script to be applied to another
instance.
The basic idea is that the AdapterFactoryEditingDomain specializes
createCommand so that it can record in the command stack the mapping
from the created command to the command parameter that created it.
Thus, when the command is actually executed, the data for how it was
created is available and can be recorded. You could reuse that type of
design.
A different and perhaps better alternative is to use a ChangeRecorder to
build a ChangeDescription which is a model object you can serialize like
any other EMF model object. There's even a ChangeCommand that uses a
ChangeRecord to allow arbitrary model changes to be applied (i.e.,
changes that don't use commands and don't know about them), and still
have the action be undoable.
Tobias Buhr wrote:
> Hi group,
>
> when searching for a way to persist the (Basic)CommandStack, I found the
> class org.eclipse.emf.mapping.command.PersistentCommandStack in the
> org.eclipse.emf.mapping plugin.
>
> Unfortunately, I neither find any documentiation nor a sample for it's
> usage.
>
> Can somebody help me out?
>
> Furthermore I think, for it's invokation one needs to use the
> AdapterFactoryMappingDomain instead of the common
> AdapterFactoryEditingDomain - but how do I provide the neccessary
> mappingDomainAdapterFactory for it's creation?
>
> Thanks for your time,
>
> Tobias
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Persist command stack: PersistentCommandStack / AdapterFactoryMappingDomain [message #414473 is a reply to message #414470] |
Thu, 08 November 2007 14:30 |
| Eclipse User |
|
|
|
Originally posted by: tobiasbuhr.gmx.de
Thanks for your reply, Ed!
> A different and perhaps better alternative is to use a ChangeRecorder to
> build a ChangeDescription which is a model object you can serialize like
> any other EMF model object. There's even a ChangeCommand that uses a
> ChangeRecord to allow arbitrary model changes to be applied (i.e.,
> changes that don't use commands and don't know about them), and still
> have the action be undoable.
Hmm, org.eclipse.emf.ecore.change looks good. Although I did not try it
out, I am not sure, if it would be the best solution for me (at least
out-of-the-box).
The point is, that I have a model, in which many many elements are
implicit (->recalculated after editing in the non-implicit part, not
user editable, but not volatile for performance reasons).
Thus, I suppose, the change recorder would be messed up pretty much.
Perhaps, I could customize it with some kind of filter - what do you think?
Best regards, Tobias
|
|
|
| Re: Persist command stack: PersistentCommandStack / AdapterFactoryMappingDomain [message #414476 is a reply to message #414473] |
Thu, 08 November 2007 14:52 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050305070201090308000004
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Tobias,
Features that are computed from the values of other features should be
marked as isDerived true. The change recorder won't record changes to
derived features with the assumption that changes to the non-derived
features will be sufficient. I'm not sure if in your case undoing only
the changes to the non-derived (non-computed) features will result in
the derived ones being recomputed to the correct undone state as well...
Tobias Buhr wrote:
> Thanks for your reply, Ed!
>
>
>> A different and perhaps better alternative is to use a ChangeRecorder to
>> build a ChangeDescription which is a model object you can serialize like
>> any other EMF model object. There's even a ChangeCommand that uses a
>> ChangeRecord to allow arbitrary model changes to be applied (i.e.,
>> changes that don't use commands and don't know about them), and still
>> have the action be undoable.
>>
>
> Hmm, org.eclipse.emf.ecore.change looks good. Although I did not try it
> out, I am not sure, if it would be the best solution for me (at least
> out-of-the-box).
>
> The point is, that I have a model, in which many many elements are
> implicit (->recalculated after editing in the non-implicit part, not
> user editable, but not volatile for performance reasons).
>
> Thus, I suppose, the change recorder would be messed up pretty much.
> Perhaps, I could customize it with some kind of filter - what do you think?
>
> Best regards, Tobias
>
--------------050305070201090308000004
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tobias,<br>
<br>
Features that are computed from the values of other features should be
marked as isDerived true.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Persist command stack: PersistentCommandStack / AdapterFactoryMappingDomain [message #414481 is a reply to message #414476] |
Thu, 08 November 2007 17:30 |
| Eclipse User |
|
|
|
Originally posted by: tobiasbuhr.gmx.de
Thanks again Ed, you paved me the way!
> Features that are computed from the values of other features should be
> marked as isDerived true. The change recorder won't record changes to
> derived features with the assumption that changes to the non-derived
> features will be sufficient.
That is great - exactly what I need.
> I'm not sure if in your case undoing only
> the changes to the non-derived (non-computed) features will result in
> the derived ones being recomputed to the correct undone state as well...
Well, that's a drawback, I have to trigger the calculation of the
derived features after I perform a FeatureChange.apply(AndReverse). But
I can live with it.
Guten Abend (GMT+1), Tobias
|
|
|
Goto Forum:
Current Time: Sat Apr 27 03:47:02 GMT 2024
Powered by FUDForum. Page generated in 0.03106 seconds |
] 
Search
Help
Register
Login
Home
