I am confused by the use of the SerializableBiPredicate<TARGET, TARGET> equalityPredicate in the Binder. In particular, I do not understand why it is not used in the initFieldValue equality check.
I have a couple of use cases where the “round-trip between model-value to presentation-value back to model-value” is imprecise:
A CustomField displaying a java Instant. Sometimes we want to see all 9 digits on the nanoSecond, but sometimes we don’t.
A CustomField displaying a Double with variable formatting, e.g., different precision or scale, and switching between decimal notation and scientific-notation depending on the value.
Both of the above cases use a simple TextField and Converter. But the Converter has to deal with a potential loss of precision.
When I attempt this, the Binder.initFieldValue determines that the originalValue and convertedValue are different, so it calls the setter.
I suppose I can hack the code to ignore the setter, i.e., the setter is replaced with a wrapper that only calls the real setter if the values are “actually” different.
However, I was hoping to use the equalityPredicate to do this instead. And that is when I realized I don’t understand the purpose and documentation of the equalityPredicate.
Ah, it really is that simple. I had not seen convertBackToPresentation in the documentation so I ignored it when it was staring me in the face in the Binder.initFieldValue method. Thank you.
Hmm. Am I just slow or am I seeing a bug? Looking at the latest version 24.6.0. Seems to me that convertBackToPresentation is ignored when calling setBean: The BindingImpl.setBean(bean) (line 2358) method calls BindingImpl.initFieldValue(bean, writeBackChangedValues=true) (line 2372).
The BindingImpl.initFieldValue methods ignores convertBackToPresentation. Why is line 1535 not if (writeBackChangedValues && convertBackToPresentation && setter != null && !readOnly)?
Also, aesthetically a little odd that so many other properties are passed into BindingImpl via the Builder but convertBackToPresentation is an exception, and has to get called after BindingBuilder.bind(getter, setter).
I wandered over to the very interesting RFC: Moving towards validators in fields - #25 by Leif. I am fully in the “Displaying data should never change data” camp and also surprised that convertBackToPresentation does not default to false.