Description Dave Orme 2005-12-05 11:18:16 EST

Currently we have invented *two* ways to keep data in sync: IUpdatable, which is our API, and an internal API we just as a special case in our support for table and table viewers.

There are several problems with this:

1) The simplest possible implementation of Undo/Redo support is described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=116465#c0.  It relies on being able to capture all editing events in the data binding framework by wrapping the JavaBeansUpdatable** classes in UndoableUpdatableValue, and UndoableUpdatableCollection objects.  When the wrapper class receives a request to change a value or a collection, instead of directly editing the value or collection, it creates a command object that it places on Eclipse's undo/redo stack, that implements the actual edit, undo, and redo using a real JavaBeansUpdatable object.

However, since some of our edits don't go through the IUpdatable interface, it becomes impossible for clients to override the editor behavior in important cases like custom undo/redo.

2) Field-level validation is already implemented using IUpdatable.  By using a custom update mechanism in tables, we have to have a custom validation mechanism.  This validation mechanism suffers from the same deficiency as the editing mechanism: It can't be overridden by clients.  Why would somebody want to override it?  Here's one use-case that has come up on the newsgroups: masked editing.

All of this points to the need for *all* editors in the data binding framework to use IUpdatable or some varient that is a part of the public API.