Nested Undo (Don't Try This At Home)

tsmo posted on Tuesday, August 01, 2006

Given a parent object with a child object, the following use case fails with CSLA's undo implementation:

1) Begin an edit on the parent. (child has state "A")

2) Begin an edit on the child. (child still has state "A")

3) Make a change on the child (child has state "B")

4) Begin an edit on the child.  (child still has state "B")

5) Make a change on the child. (child has state "C")

6) Cancel edit on the parent.

The expected result would be that the child would now have state "A", as it did when the parent began its current edit.  The actual result is that the child is restored to state "B".

From stepping through the code it seems that the reason for this is that UndoEdit's cascade un-does the last edit on the child's scope, rather than the parent's. 

I've got a feeling that there's a pragmatic explanation for this behavior having to do with memory use, and that this isn't so much a bug as a lack of support for bizarre and reckless behavior.  In any case, I'd love to know the technical reasons behind this situation.

Thanks,
tsmo

RockfordLhotka replied on Wednesday, August 09, 2006

I think I answered this and then the server's hard drive crashed...

The answer is that n-level undo requires that every BeginEdit() call on an object have a matching CancelEdit() or ApplyEdit() on that same object, within the same call scope.

In other words, n-level undo is a nested operation, and each call to BeginEdit() creates a new nesting level that must be committed or rolled back before any previous level is committed or rolled back.

For details see Chapter 3.