Home » Modeling » EMF » Getting the ChangeDescription of an AbstractEMFOperation
| Getting the ChangeDescription of an AbstractEMFOperation [message #416466] |
Sun, 03 February 2008 18:43  |
Eclipse User |
|
|
|
Originally posted by: mariusheinzmann.yahoo.de
Hi everybody,
we have developed an extended EMF model Editor that is a slightly
modified EcoreEditor, which opens specialised editors on double click,
depending on the selected EClass.
Since all these editors work directly on the model we integrated the
EMF.transaction framework via the workspace integration. Every
specialised Editor has its own undo/redo history context and on saving
the changes are propagates to the main EcoreEditor. So the main Editor's
undo/redo history does not reflect all changes done in the specialised
editors, but big chunks of changes that propagated in a kind of compound
operation that contains already executed operations.
There is one big problem left, though. Since we are working directly on
the model from all editors and not all changes are reflected by the
undo/redo history of the main editor, we may run into chronological
problems.
Example:
MEE = main EcoreEditor, SE = specialised editor.
Lets assume we have saved some changes done in SE and then done some
more changes. Now SE is dirty and contains local changes in the
undo/redo history and MEE contains only one change (the compound changes
done in SE until saved). If the user is in MEE and undoes the changes
from SE, this action may result in an inconsistent state, if the changes
are not disjoint. Because then the rollback of changes in MEE would
override changes done later in SE and SE wouldn't recognise this.
To prevent this from happening it would be great to have access to the
ChangeDescription of the AbstractEMFOperations, but the getter is
protected final and even the trick with a helper class being in the same
package but in another jar file doesn't work. I get an IllegalAccess
Exception and I'm not sure why, because if the package is sealed (I
can't find any clues as to why it is) it should be an SecurityException
about sealing.
Anyway, I'd really appreciate if this description would be made public,
or if anyone can tell me how to get this information via another approach.
Thanks in advance!
|
|
|
| Re: Getting the ChangeDescription of an AbstractEMFOperation [message #416470 is a reply to message #416466] |
Mon, 04 February 2008 10:48  |
| Eclipse User |
|
|
|
Originally posted by: Marius.NightLabs.de
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi again,
to complement my previous post, here is some more information on what I
am trying to do.
If I would be able to get the ChangeDescription, then I could hook an
IOperationApprover into the OperationHistory to check if there is a
dirty open editor for the affected classes of an AbstractEMFOperation
and can ask the user whether he/she really wants to procede and hence
undo the local changes of these editors.
In order to retrieve the ChangeDescription I tried the HelperClass
approach that sits in the same package and hence has acces to the
getChange method of an AbstractEMFOperation, but Eclipse seems to
disallow such an access.
The ugly second approach was via reflection. This way I got the
ChangeDescription, but when I try to iterate over the keyset of the
object changes (description.getObjectChanges().keyset()), I get the
following exception:
java.lang.ArrayStoreException:
org.eclipse.emf.ecore.change.impl.EObjectToChangesMapEntryIm pl
at org.eclipse.emf.common.util.BasicEList.assign(BasicEList.jav a:191)
at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList. java:645)
at org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:6 26)
at org.eclipse.emf.common.util.BasicEMap.doPut(BasicEMap.java:6 16)
at
org.eclipse.emf.common.util.BasicEMap.ensureEntryDataExists( BasicEMap.java:247)
at
org.eclipse.emf.common.util.BasicEMap$BasicEMapIterator.scan (BasicEMap.java:1215)
at
org.eclipse.emf.common.util.BasicEMap$BasicEMapIterator.<init >(BasicEMap.java:1194)
at
org.eclipse.emf.common.util.BasicEMap$BasicEMapKeyIterator.<init >(BasicEMap.java:1310)
at org.eclipse.emf.common.util.BasicEMap$3.iterator(BasicEMap.j ava:880)
This only occurs on the first try, on the second try, the view is
already instantiated but empty.
To summarise, I think the access to the ChangeDescription of an
AbstractEMFOperation would be appreciative since it would open up the
possibility to scan the affected objects from a given operation.
Does anybody know how to get to the ChangeDescription from an Operation,
or maybe I missed the right way to use the API and am badly working
around it. (I hope not! :-))
All comments are appreciated!
Marius H.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHpu2PuSHKxXSCvdcRAnFaAKC0e/dkNI52/HKZhaUGjTewMGSpEwCe IB5N
THxTdkRbokqDYwhshl+T+Uk=
=Ku7X
-----END PGP SIGNATURE-----
|
|
|
| Re: Getting the ChangeDescription of an AbstractEMFOperation [message #416471 is a reply to message #416466] |
Mon, 04 February 2008 12:46 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Marius,
Why should the changes in your subordinate editors be propagated to the
parent editor only on save? If they are editing the same resource (or, at
least, the same resource set), then all of these changes can be reflected
immediately in the parent editor (because they are manifestly applied to
what the editor is editing, already). The advantage of the operation
history is that it allows integration of undo/redo across all of these
editors. An undo in the parent editor can, if necessary, undo changes
performed by the subordinate editor, and vice-versa.
Would it not be more transparent to the user to surface the changes made in
subordinate editors on the undo menu of the parent editor, as they occur?
As an alternative to the change description, you might perhaps tag the
operation with "affected objects" after the fashion of EMF's Commands.
This could be accomplished with an IUndoContext, somewhat akin to the
ResourceUndoContext in the org.eclipse.emf.workspace plug-in but
identifying EObjects.
Cheers,
Christian
Marius Heinzmann wrote:
> Hi everybody,
>
> we have developed an extended EMF model Editor that is a slightly
> modified EcoreEditor, which opens specialised editors on double click,
> depending on the selected EClass.
>
> Since all these editors work directly on the model we integrated the
> EMF.transaction framework via the workspace integration. Every
> specialised Editor has its own undo/redo history context and on saving
> the changes are propagates to the main EcoreEditor. So the main Editor's
> undo/redo history does not reflect all changes done in the specialised
> editors, but big chunks of changes that propagated in a kind of compound
> operation that contains already executed operations.
>
> There is one big problem left, though. Since we are working directly on
> the model from all editors and not all changes are reflected by the
> undo/redo history of the main editor, we may run into chronological
> problems.
>
> Example:
> MEE = main EcoreEditor, SE = specialised editor.
>
> Lets assume we have saved some changes done in SE and then done some
> more changes. Now SE is dirty and contains local changes in the
> undo/redo history and MEE contains only one change (the compound changes
> done in SE until saved). If the user is in MEE and undoes the changes
> from SE, this action may result in an inconsistent state, if the changes
> are not disjoint. Because then the rollback of changes in MEE would
> override changes done later in SE and SE wouldn't recognise this.
>
> To prevent this from happening it would be great to have access to the
> ChangeDescription of the AbstractEMFOperations, but the getter is
> protected final and even the trick with a helper class being in the same
> package but in another jar file doesn't work. I get an IllegalAccess
> Exception and I'm not sure why, because if the package is sealed (I
> can't find any clues as to why it is) it should be an SecurityException
> about sealing.
> Anyway, I'd really appreciate if this description would be made public,
> or if anyone can tell me how to get this information via another approach.
>
> Thanks in advance!
|
|
|
| Re: Getting the ChangeDescription of an AbstractEMFOperation [message #416513 is a reply to message #416471] |
Wed, 06 February 2008 08:49 |
| Eclipse User |
|
|
|
Originally posted by: Marius.NightLabs.de
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Christian,
> Why should the changes in your subordinate editors be propagated to the
> parent editor only on save? If they are editing the same resource (or, at
> least, the same resource set), then all of these changes can be reflected
> immediately in the parent editor (because they are manifestly applied to
> what the editor is editing, already). The advantage of the operation
> history is that it allows integration of undo/redo across all of these
> editors. An undo in the parent editor can, if necessary, undo changes
> performed by the subordinate editor, and vice-versa.
> Would it not be more transparent to the user to surface the changes made in
> subordinate editors on the undo menu of the parent editor, as they occur?
That's true, we've thought about that as well.
The problem that arises when using this approach is that there are tons of
tiny changes in the undo history. This confuses the user and we decided to
pack all the small changes into bigger portions.
> As an alternative to the change description, you might perhaps tag the
> operation with "affected objects" after the fashion of EMF's Commands.
> This could be accomplished with an IUndoContext, somewhat akin to the
> ResourceUndoContext in the org.eclipse.emf.workspace plug-in but
> identifying EObjects.
Thanks for the idea. We implemented it that way, but the generic
approach via the ChangeDescription seems even more appealing, since we
don't have to maintain the information about which classes are edited by
the editor.
There already is the case where changes on one EClass affect Metadata of
another EClass (information serialised into EAnnotations of that EClass).
You might wonder why we need to store MetaData in EAnnotations, well, we
are porting a huge Rose model of a software that even modelled all of
the GUI!
Anyway, is there a particular reason for the ChangeDescription not being
accessible?
Thanks for your feedback! :)
Marius
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHqXSAuSHKxXSCvdcRAqFeAJ9MlhFRWKRWga+pf7CD1HBhM8GJFQCg jFws
vE9Zo0LDqh37jTo1U8Iv79I=
=acot
-----END PGP SIGNATURE-----
|
|
|
| Re: Getting the ChangeDescription of an AbstractEMFOperation [message #416629 is a reply to message #416513] |
Fri, 08 February 2008 14:29 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Marius,
Find some more comments in-line, below.
Cheers,
Christian
Marius Heinzmann wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Christian,
>
>> Why should the changes in your subordinate editors be propagated to the
>> parent editor only on save? If they are editing the same resource (or,
>> at least, the same resource set), then all of these changes can be
>> reflected immediately in the parent editor (because they are manifestly
>> applied to
>> what the editor is editing, already). The advantage of the operation
>> history is that it allows integration of undo/redo across all of these
>> editors. An undo in the parent editor can, if necessary, undo changes
>> performed by the subordinate editor, and vice-versa.
>> Would it not be more transparent to the user to surface the changes made
>> in subordinate editors on the undo menu of the parent editor, as they
>> occur?
>
> That's true, we've thought about that as well.
> The problem that arises when using this approach is that there are tons of
> tiny changes in the undo history. This confuses the user and we decided to
> pack all the small changes into bigger portions.
Ah. Perhaps, then, the IOperationHistory's notion of an "open composite"
will help? In the 1.2 release, the EMF Transaction component now correctly
handles the execution of AbstractEMFOperations while the history has a
composite open. This would automatically aggregate all of your subordinate
editor's commands into one undoable unit.
It it's not practical to maintain an open composite, for example because the
user can work simultaneously in multiple subordinate editors, then a
strategy of retroactively composing the operations into your own kind of
composite might work.
>> As an alternative to the change description, you might perhaps tag the
>> operation with "affected objects" after the fashion of EMF's Commands.
>> This could be accomplished with an IUndoContext, somewhat akin to the
>> ResourceUndoContext in the org.eclipse.emf.workspace plug-in but
>> identifying EObjects.
> Thanks for the idea. We implemented it that way, but the generic
> approach via the ChangeDescription seems even more appealing, since we
> don't have to maintain the information about which classes are edited by
> the editor.
> There already is the case where changes on one EClass affect Metadata of
> another EClass (information serialised into EAnnotations of that EClass).
>
> You might wonder why we need to store MetaData in EAnnotations, well, we
> are porting a huge Rose model of a software that even modelled all of
> the GUI!
Well, that's exactly what annotations are for. Sounds like a big job!
> Anyway, is there a particular reason for the ChangeDescription not being
> accessible?
Yes. It's an implementation detail that I just don't want to expose in the
API without a compelling general use case. Note that you can always, if
you need to, encapsulate an AbstractEMFOperation in a ChangeDescription
using the OperationChangeDescription. This can even be composed with other
changes using a CompositeChangeDescription.
> Thanks for your feedback! :)
> Marius
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHqXSAuSHKxXSCvdcRAqFeAJ9MlhFRWKRWga+pf7CD1HBhM8GJFQCg jFws
> vE9Zo0LDqh37jTo1U8Iv79I=
> =acot
> -----END PGP SIGNATURE-----
|
|
|
Goto Forum:
Current Time: Tue Apr 23 15:47:01 GMT 2024
Powered by FUDForum. Page generated in 0.02866 seconds |
] 
Search
Help
Register
Login
Home
