#21 cancel tree for contained add
Say MessageClass01 contains an array of
MessageClass02 objects, and MessageClass02 in turn
contains an array of MessageClass03 objects. Note
that these are actual contained objects, not
references.
Now let's say you are editing M01 and you click to
append a new M02. Your position is now
M01.M02[-1]
While adding M02, you click to append a new M03.
Without any special processing, your position would
now be
M01.M02[-1].M03[-1]
which makes it impossible to resolve the parent of
M03 to anything real from the context of the root
message.
The current solution (which is generally fine) is
to commit the addition of M02, when the user clicks
to add M03. That means "cancel" ceases to be a
real option for the add of M02. This is usually
acceptable because
- these aren't persistent objects, so the updates
aren't usually being tracked, just merged back
into the root object.
- making the user jump through hoops to add a new
tree branch is not good, and this is the best
we can do without storing more context.
If we stored more context, then we could support a
cancel/commit option at each branch of the tree.
However we do NOT want to add any additional
complexity to the UIFormContext just for this
issue, because it's a fairly isolated case.
Note that:
- most editing is of persistent objects and this
issue doesn't come up for references
- this hasn't been much of a problem in practice
So the task is to store more context in the same
structure. Probably the most relevant aspects of
that structure are the position indicator and the
root object. There are probably several approaches
here.
The general case solution to this pattern is to
create Action objects, which hold both the cancel
and commit context, and then keep a stack of
actions. This is the usual way of providing
undo/redo etc processing. However this may be
overkill for handling this one situation.
Another option would be to create a BranchAdd
object to handle just this particular case, and
then use a supplemental position encoding to handle
this particular situation.
Any solution should be proposed and discussed on the
dev list first.
