Re: Undo/redo implementation & JMI compliance

Holger Krug wrote:
> On Wed, Jun 26, 2002 at 04:11:12PM +0200, Svata Dedic wrote:
> 
> 
> Think of the case when in one transaction first EVENT_ATTRIBUTE_SET
> and then EVENT_INSTANCE_DELETE is fired. In the post-transaction event
> handler even for EVENT_ATTRIBUTE_SET the object identity will not
> available any more, when the object identity is determined by the

I wonder if there's a need to access the RefObject instance (except for 
its mofid) in the case of ATTR_SET event at all. The old and new 
attribute's value should be send with the event, shouldn't they ? Does 
Undo/Redo need more info about the object than the precise 
attribute/association link which has been changed ?

[...]
> remote repositories. I think the Undo/Repo implementation is allowed
> to formulate an SPI to be implemented by repository implementations to
> be able to use Undo/Redo management. That SPI comprises JMI and adds
> the repository interface with it's one method. I do not require to add
> lookup by mofId to the JMI spec. But I require to provide services
> above JMI to be able to use the Undo/Redo implementation. And this
> services are trivial at least for MDR.
> 
Thanks for the explanation (and yes: if there's an abstract description 
of a model change, you have to be able to _effectively_ lookup the 
instance given some abstract ID in order to apply / revert the change on 
that very instance; mofid being the best id ever).

I admit I didn't think about the implementation in-depth... so wouldn't 
it make more sense (and less wasted time for you) if I wait for some 
rough design document before arguing further ;-) ?

Thanks!
-- 
Svatopluk Dedic            <mailto:[email protected]>
NetBeans, Java/Repository  <http://java.netbeans.org>