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

["Christian W. Damus" <cdamus@xxxxxxxxxx>]

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!