Generic Undo-Framework?

All,

I am looking (for a customer) for existing work and possibly services for a
generic Undo-framework for VisualWorks 7.5.

Background: my customer has a GUI application with a sophisticated and
rather complex domain model, which up to now was very resistant against
implementing Undo functionality. The domain model is too complex and large
to be stored as a whole for Undo steps.

Possible solutions that we discussed where to model and record macro (GUI)
activities on the domain that entail their own undo.
Also on the other end of the spectrum we think about a transactional system
on the domain itself, where each GUI activity would trigger one
transactional context to be unrolled on Undo. Because of the complexity of
the domain logic, such transaction system needs to be put ontop of the
domain classes transparently (e.g. MethodWrapper technology)

Does anyone know of work on generic solutions for such Undo functionality?
Presentations, papers, frameworks?

Thank you,

Andreas

--
Andreas Tönne
Lead Consultant
Cincom Systems GmbH & Co. oHG
Tel.: +49 6196 9003 100
Mobile: +49 172 6159272

Geschäftsführer/Managing Directors: Thomas M. Nies, Gerald L. Shawhan
oHG mit Sitz/based in Schwalbach/Ts. (Amtsgericht Königstein/Ts. HRA
2653)
Pers. haftender Gesellschafter/Partner liable to unlimited extent:
Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht Königstein/
Ts. HRB 5069)

I'm aware of two classes of mechanisms for modelling such things. One is by using the Command pattern, where commands know how to undo themselves, as used in the Refactoring Browser. However, this could be hard to retrofit onto a large existing system. The other is to do some level of copying and be able to revert it. An example of this can be found in ObjectTransaction in Glorp. The ObjectTransaction class has minimal dependencies on the rest of Glorp, mostly for Dialect portability operations, and would be quite easy to extract.

The difficulty with the copying approaches is that you don't want to copy the entire transitive closure of domain objects, and you also want to avoid copying non-domain objects (e.g. blocks, their containing methods, their containing classes, their superclasses and subclasses, etc.). If using Glorp, or something similar, then the constraint is fairly easy. Non-persistent objects don't count, and you are likely to have uninstantiated proxies as stopping points.

In a more general context, you would need to define a way to register the transitive closure from an object you were interested in, and define stopping points for it. I had reasonable success just stopping at blocks, classes, and primitives, but that was for fairly simple usage.

At 09:24 AM 1/7/2008, Andreas Tönne wrote:

All,

I am looking (for a customer) for existing work and possibly services for a
generic Undo-framework for VisualWorks 7.5.

Background: my customer has a GUI application with a sophisticated and
rather complex domain model, which up to now was very resistant against
implementing Undo functionality. The domain model is too complex and large
to be stored as a whole for Undo steps.

Possible solutions that we discussed where to model and record macro (GUI)
activities on the domain that entail their own undo.
Also on the other end of the spectrum we think about a transactional system
on the domain itself, where each GUI activity would trigger one
transactional context to be unrolled on Undo. Because of the complexity of
the domain logic, such transaction system needs to be put ontop of the
domain classes transparently (e.g. MethodWrapper technology)

Does anyone know of work on generic solutions for such Undo functionality?
Presentations, papers, frameworks?

Thank you,

Andreas

Alan,

thank you. I meant the Command pattern (am I too old to rethink my Smalltalk in stylish patterns? :-) when I wrote about modeling macro activities. Thank you for pointing me to the RB and ObjectTransaction. Copying, even with cleverly defined closures, is out of scope. The domain is a complex graph of significant size but unfortunatly some activities can have global consequences, e.g. triggering re-routing. Hence the alternative idea of recording changes at the instvar level.

Andreas

Am 07.01.2008 15:38 Uhr schrieb "Alan Knight" unter <[hidden email]>:

I'm aware of two classes of mechanisms for modelling such things. One is by using the Command pattern, where commands know how to undo themselves, as used in the Refactoring Browser. However, this could be hard to retrofit onto a large existing system. The other is to do some level of copying and be able to revert it. An example of this can be found in ObjectTransaction in Glorp. The ObjectTransaction class has minimal dependencies on the rest of Glorp, mostly for Dialect portability operations, and would be quite easy to extract.

The difficulty with the copying approaches is that you don't want to copy the entire transitive closure of domain objects, and you also want to avoid copying non-domain objects (e.g. blocks, their containing methods, their containing classes, their superclasses and subclasses, etc.). If using Glorp, or something similar, then the constraint is fairly easy. Non-persistent objects don't count, and you are likely to have uninstantiated proxies as stopping points.

In a more general context, you would need to define a way to register the transitive closure from an object you were interested in, and define stopping points for it. I had reasonable success just stopping at blocks, classes, and primitives, but that was for fairly simple usage.

At 09:24 AM 1/7/2008, Andreas Tönne wrote:

All,

I am looking (for a customer) for existing work and possibly services for a

generic Undo-framework for VisualWorks 7.5.

Background: my customer has a GUI application with a sophisticated and

rather complex domain model, which up to now was very resistant against

implementing Undo functionality. The domain model is too complex and large

to be stored as a whole for Undo steps.

Possible solutions that we discussed where to model and record macro (GUI)

activities on the domain that entail their own undo.

Also on the other end of the spectrum we think about a transactional system

on the domain itself, where each GUI activity would trigger one

transactional context to be unrolled on Undo. Because of the complexity of

the domain logic, such transaction system needs to be put ontop of the

domain classes transparently (e.g. MethodWrapper technology)

Does anyone know of work on generic solutions for such Undo functionality?

Presentations, papers, frameworks?

Thank you,

Andreas

--
Andreas Tönne
Lead Consultant
Cincom Systems GmbH & Co. oHG
Tel.: +49 6196 9003 100
Mobile: +49 172 6159272

Geschäftsführer/Managing Directors: Thomas M. Nies, Gerald L. Shawhan
oHG mit Sitz/based in Schwalbach/Ts. (Amtsgericht Königstein/Ts. HRA 
2653)
Pers. haftender Gesellschafter/Partner liable to unlimited extent:
Cincom Systems Verwaltungsgesellschaft mbH (Amtsgericht Königstein/
Ts. HRB 5069)

OK, although I will note that copying often isn't nearly as expensive as people think it might be.