Re: Undo/redo implementation & JMI compliance

Hi Holger,
Svata is right - I think that's how this should be handled. Just a small 
but important note - the event object that comes from pre-change event 
is the identical object to the one that comes from changed/canceled 
event (i.e. preChangeEvent == postChangeEvent). This way you can easily 
find the data that you gathered during the planned-change event in your 
"changed" event.
Hopefully this helps.
Martin

Svata Dedic wrote:
> Hello, Holger,
> 
> Holger Krug wrote:
> 
>> The following problem appears which I want to discuss shortly before
>> proceeding with my work:
>>
>> When the undo/redo manager (short: UndoManager) is informed e.g. about
>> link deletion it receives a call like:
>>
>>  linkDeleted(RefAssociation a1, RefObject o1, RefObject o2)
>>
>> Unfortunately when this method is called o1 may already have been
>> deleted from the repository ! Hence calls to o1.refClass(), 
>> o1.refMofId() etc.
>> may fail. In the case of MDR o1.refClass() will fail, but 
>> o1.refMofId() not.
>> On the other hand the UndoManager must extract information necessary to
>> identify o1, i.e. it must know the class proxy and the mofId.
> 
> 
> There are two kinds of Listeners. So called pre-change and post-change 
> ones. The pre-change listeners get the event *before* the action takes 
> place. They are called synchronously with the operation itself and 
> within the same transaction. Post-change are notified asynchronously, 
> after the transaction completes.
> The listener registration call is *the same* for both types, the 
> implementation decides by the listener's type which events it will get. 
> Typically a a client, which wants pre-change events will be interested 
> in the same post-change events in almost all cases.
> 
> You can store away object's properties when you get plannedChange() 
> describing object deletion. Later, your listener will get either 
> changeCancelled() or change(), depending on whether the transaction was 
> rolled back or committed. You can then write out your data gathered in 
> the pre-change handler to the history file or discard it from memory.
> 
> -Svata
>