Re: Undo/redo implementation & JMI compliance

On Wed, Jun 26, 2002 at 02:44:17PM +0200, Svata Dedic wrote:

> There are two kinds of Listeners. So called pre-change and
> post-change ones.  You can store away object's properties when you
> get plannedChange() describing object deletion.

Thank you Svata for the tip. I knew this. As you can see from my mail
and also from what Brians last mail on the `UNDO/REDO management'
thread was targeted on I'm looking for a solution which is able to
work for several JMI implementations. Nevertheless you're right I can
use pre-change listeners to adapt the MDR event handling mechanism to
a generic UndoManager. But is seems quite a heavy overhead for every
e.g. EVENT_ATTRIBUTE_SET to store away all necessary data to be
prepared for the case that the source object is deleted later on in
the same transaction.

Furthermore because I want to have persistent undo/redo support I must
uniquely identify each repository object in a serializable way. IMHO
JMI allows to do this for instance objects only by a combination of
fully qualified names and mofIds. Quite odd, when almost every JMI
implementation should be able to provide a fast lookup by mofId. This
slows down undo/redo further. Hence my proposal to add an interface
Repository with an operation:

RefBaseObject Repository.getByMofId(String mofId) throws SomeException 

Any JMI implementation which wants to use the Undo/Redo manager must
provide an implementation of this interface and must allow to call
RefBaseObject.refMofId() in the after deletion event handlers. This
seems not to be to difficult, it will speed up undo/redo management
significantly and reduce complexity of UndoManager implementation
also.

I will publish my proposed undo/redo API soon, probably
tomorrow. Nevertheless any further comments are welcome.

-- 
Holger Krug
[email protected]