[news.eclipse.tools.emf] Re: Getting the ChangeDescription of an Abstrac

[Marius Heinzmann <Marius@xxxxxxxxxxxx>]

-----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+pf7CD1HBhM8GJFQCgjFws
vE9Zo0LDqh37jTo1U8Iv79I=
=acot
-----END PGP SIGNATURE-----