Community
Participate
Working Groups
One of the fundamental principles of the data binding framework is that when a user changes a value in a user interface and that value is saved to an IUpdatable object, that change is automatically propogated to all other IUpdatable objects that are linked to the original object. Thus all places in the user interface are automatically kept in sync with all changes. Unfortunately, tables don't currently work this way, which breaks the user's expectation that all data she can see is always accurate and up to date. Other negative side effects of this implementation decision are that implementing Undo/Redo in terms of IUpdatables works for everything except for tables. A third negative side effect is that validators aren't applied to fields that are being edited inside a table, providing an opportunity for inconsistent validation rules to be applied throughout an application. A fourth negative side effect is that if we ever implement a masked edit validator, masked editing will work everywhere except for in tables. ...and so on.
Changing severity to blocker since my current client won't accept the data binding framework until this problem is solved, for all of the reasons listed above.
I can see there is a problem with implementing a generic undo/redo given the current table story, but I don't understand why you say the current table implementation does not keep everything up to date. Could you clarify what you mean by "up to date"? Changes in the model show up in the table immediately, and changes in the table affect the model. The changes just don't go through any kind of IUpdatable or Binding mechanism.
(In reply to comment #2) > I can see there is a problem with implementing a generic undo/redo given the > current table story, but I don't understand why you say the current table > implementation does not keep everything up to date. Could you clarify what you > mean by "up to date"? Changes in the model show up in the table immediately, and > changes in the table affect the model. The changes just don't go through any > kind of IUpdatable or Binding mechanism. Okay, I misunderstood. I didn't realize that we have invented *two* ways to keep stuff in sync: IUpdatable and whatever we are using to keep tables in sync. I retract my point #1, but I think that points #2, #3, and #4 still stand. :-) If it turns out that we need Undo/Redo support than the severity of this will become blocker again, but right now that is just a critical thing (it doesn't stop development at the moment, but it could easily in the future). Reducing severity to critical.
Just to record some ideas from a discussion with Dave: public interface ICellProvider { public Object getCellValue(Object element, int columnIndex); public Object getCellType(Object element, int columnIndex); public void setCellValue(Object element, int columnIndex, Object value); } public interface IModelTable extends ICellProvider { public IList getElementsUpdatable(); } public interface ITargetTable { public IUpdatableCollection getElementsUpdatable(); public void setCellProvider(ICellProvider provider); }
Fixed > HEAD 20060206 Must use the new TableModelDescription when creating the table in order to get this behavior.
Marking as VERIFIED without actually verifying individually since a complete refactoring of the data binding framework will be released soon.
