Comment 1 Dave Orme 2005-12-15 12:27:48 EST

Suppose we have two classes:

a) Address
b) AddressEditor

Address naturally contains a State object that is bound to the value of a ComboViewer.

AddressEditor contains a validStates property.  This property is bound to the contents of the ComboViewer.  The states listed inside the validStates property depend on the value of a postal code field.

Suppose we have some other property "foo" in AddressEditor that is also bound.  Whenever "foo" changes, both "foo" and "validStates" will be refreshed because data binding is listening to the generic property change listener.

However, the first thing that CollectionBinding does when refreshing the contents of the ComboViewer is to remove all the existing State objects in the viewer.  This has the side-effect of also clearing the "value" of the ComboViewer.

The result is that changing any property that is bound to AddressEditor causes loss of the value in the "state" combo.

Since this bug results in a "loss of data", I am marking this bug as critical, per the definitions listed under "Severity".

Comment 2 Scott Delap 2005-12-16 17:32:15 EST

Quick note: We just got bit by this bug hard a second time.

Comment 3 Dave Orme 2005-12-19 15:10:25 EST

Fixed and committed for JavaBeansUpdatableValue.

IUpdatableCollection in general and JavaBeansUpdatableCollection in particular have the following problems:

1) Not virtual.

2) Fixing this bug means that we have to introduce a central registry for collections that are being edited.  Otherwise updates won't propogate between identical collections that are being edited in two places.

Solutions to these two problems conflict.  Documenting these problems so we can think about this more before attacking them.

Comment 4 Dave Orme 2005-12-20 14:52:09 EST

*** Bug 121537 has been marked as a duplicate of this bug. ***

Comment 5 Dave Orme 2005-12-23 15:31:22 EST

*** Bug 121044 has been marked as a duplicate of this bug. ***

Comment 6 Dave Orme 2006-01-06 16:29:01 EST

*** Bug 118452 has been marked as a duplicate of this bug. ***

Comment 7 Dave Orme 2006-02-02 17:10:45 EST

Fixed > HEAD 20060202.

For TableViewers, in order to get this behavior, you have to bind them as follows:

dbc.bind(new Property(ordersViewer, ViewersProperties.CONTENT),
	new TableModelDescription(new Property(selectedPerson,
		"orders", List.class, Boolean.TRUE), new Object[] {
		"orderNumber", "date" }), null);

using a TableModelDescription on the model side in order to indicate the columns that will be bound.  These are the columns that will be listened to for changes.

See the TestMasterDetail class in the examples plug-in for details.

Comment 8 Boris Bokowski 2006-02-16 12:55:10 EST

Marking as VERIFIED without actually verifying individually since a complete
refactoring of the data binding framework will be released soon.