JavaBeanPropertyAdapter

[Tom Eugelink]

>> Bindings for Java Bean properties will be slightly different than our usual bindings: they will be eager and they may become out-of-sync. Let's say we have a Java Bean Property p, that is bound to an ObservableValue v. Internally we hook a listener to v and propagate all changes to p by calling its setter (that is why it will be eager). If now p does not accept the value from v, p and v will be out-of-sync. Especially the last point bothers my, but I guess there is no way to ensure synchronization.
> Right, we're just sort of hosed there.

How about the if-set-then-sync-back approach? Which basically means that every time after calling the setter, you'll do an equals on the result and if it it is not equal a sync-back is started.

sync A->B:
     try
     {
         A.setter(value)
     }
     finally
     {
         if (A.getter.equals( value ) == false) // TODO: also take nulls in comparison
         {
             sync B->A
         }
     }

If this starts to loop then something is wrong in the user's code, because it has attempted to reach a state that should (can) not exist. N.B. this approach is different from the current binding logic of JavaFX, where the JavaFX side always accepts the value (if I remember correctly Richard?)




>
> Very few Java classes use VetoableChangeListeners. However, I think that is OK since the common usage here will be to either do a unidirectional binding from a JavaFX property to a POJO (for example, Label.text is bound to Customer.name), or a bidirectional binding between the two. So this seems fine.

The approach above also takes care of this scenario, via the finally construct.

Tom