Looks like binder only writes back values when none of the bindings have validation errors.
This sounds like “buffered” mode in old vaadin.
What do I need to do to get the “unbuffered” behavior?
I want to be able to ask the binder if all fields are valid
I want invalid fields to be red
I want a valid field to call its binding’s setter immediately. It should not be blocked by another invalid field
If you use setBean exactly that is happening.
There’s also binder.writeBeanAsDraft if you want to invoke a method
@quirky-zebra Not sure I understand. I’m not talking about the annoying “write back” that vaadin does when you bind a field initially. I’m talking about changes the user does when using the application.
As soon as one field is invalid, the binder stops writing back changes in any other fields as well.
@vital-koala , I could use writeBeanAsDraft if this was something I wanted on a submit button, but I want values from all fields to write back changes to the bean as they happen.
do you have a global binder::withValidation? Or only field based validation? If you have the first one: yes, that’s going to block all writings
The second one (field based validation) DOES NOT block other fields from being changed in the setBean mode - I’m 1000% sure
binder.setBean(row);
var someDate = new DatePicker("Some Date");
binder.forField(someDate).bind(Row::getSomeDate, Row::setSomeDate);
add(someDate);
var someText = new TextField("Last Name");
binder.forField(someText).bind(Row::getSomeText, Row::setSomeText);
add(someText);
If I write “x” in the DatePicker, changes in the TextField are not written to Row.
When I remove the “x” in the DatePicker, all changes are written to Row
Can’t reproduce
No, wait, I can
I think it’s got to do with the new field validations in V24
And this is, indeed, intended behavior:
You can call writeBeanAsDraft manually if you want potentially invalid values in your bean.
The idea behind both setBean and writeBean is that binder should protect the bean so that it only ever sees a valid set of values
So you could either remove the validator, or call writeBeanAsDraft in a value change listener
Yeah that’s the “invisible” date picker validation… which can be disabled in 24.4
In Vaadin 24.4, there will be Binder.setDefaultValidatorEnabled(boolean)
Even tho I would say it feels weird that the datepicker’s validation can interfere with the text field
I guess it’s a “fail fast” type of design
I don’t think it was designed with such things in mind 
Turns out that combining client-side validation and server-side validation is pretty complex!
Who would have thought.
