I don't have time to design a solution right now, but here's some info on the MDR end of things:
- NetBeans uses MDR and probably implements Undo. It might be instructive to look at how they did it. - I don't think MDR has any built-in undo facility, but it's got everything needed to build one. All changes to the repository are effectively serialized in the form of change events. The ArgoUML Model-MDR subsystem gets notified before each change with the contents of the change that is about to be made and then again after the change is made. The latter is what we propogate back to the ArgoUML application as model subsystem events. - UUIDs aren't used internally by MDR, so we already have a "synonym UUID" capability. We only maintain UUIDs because PGML requires them. MDR has two types of IDs: 1) MOF ID - managed by the repository and guaranteed unique within it for the life of the repository, and 2) xmi.id - used within a single XMI file to link various items together (type references, etc). What gets called a "UUID" is actually the MOF ID of the creating repository. We maintain an internal mapping that gets created every time a new XMI file gets read to map from this "UUID" to the current internal MOF ID. - The "Wastebasket" implementation in ArgoUML probably isn't complete. It was already unused by the time I joined the project so I made no effort to make sure that it worked with MDR correctly. Wastebaskets also - Incremental delta saves are more commonly known as "transaction logs" and are used extensively by databases and log based file systems (eg NTFS). - We have several unhealthy model repository updating practices that will need to be cleaned up to keep from interacting poorly with any MDR event based undo. Some examples include character-by-character updating of name fields and deleting then recreating entire collections just to move a single member. - Implementing individual undo/redo methods for each type of ModelElement is likely to be both tedious and error prone. I'd recommend leveraging the metamodel description to make sure all information is captured. If I had time to play with this, the approach I'd probably try to prototype first would be to take the MDR change event mechanism, add a way to insert begin/end undoable transaction markers into the event stream and store the last N transaction groups of change events for rollback. Of course none of this addresses the GEF side of the world. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
