See example below, typing a number > 1000 or a number < -1000 in the field and pressing "validate" to store it, should NEVER store the invalid values in the bean.
The javadoc of setMax also tells me:
Sets the maximum value of the field. Entering a value which is greater than code max invalidates the field.
Vaadin Version: 14.1.18
Browser: FF 74
@Route("bug-min-max")
public class IntegerFieldMinMax extends Composite<VerticalLayout> {
public IntegerFieldMinMax() {
IntegerField field = new IntegerField("Type here");
field.setMax(1000);
field.setMin(-1000);
field.addValueChangeListener(evt -> Notification.show("Changed value to: " + evt.getValue(), 3000, Position.TOP_START));
IntergerObject bean = new IntergerObject(1);
Binder<IntergerObject> binder = new Binder<>();
binder.forField(field).asRequired("Integer is required")
.bind(IntergerObject::getValue, IntergerObject::setValue);
binder.readBean(bean);
Button validate = new Button("Validate", evt -> {
if (binder.writeBeanIfValid(bean)) {
if(bean.getValue() > 1000) {
Notification.show("This is not valid - should NEVER been STORED. Field is configured with max = " + field.getMax()).addThemeVariants(NotificationVariant.LUMO_ERROR);
}else if(bean.getValue() < -1000) {
Notification.show("This is not valid - should NEVER been STORED. Field is configured with min = " + field.getMin()).addThemeVariants(NotificationVariant.LUMO_ERROR);
}
Notification.show("Stored valid value: " + bean.getValue(), 3000, Position.TOP_START);
}
});
getContent().add(field, validate);
}
@Data // Lombok Annotation
@AllArgsConstructor // Lombok Annotation
private static class IntergerObject {
private Integer value;
}
}
There are two points here which have odd behaviour:
IntegerField should not allow the user to input the values less than -1000 and more than 1000, as it's done e.g by TextArea.setMaxLength(int maxLength) method to restrict length of input characters. As a user, i'd expect this component takes care of it, before the validation inside the binder. Binder.withValidator() method is not being invoked, then it assumes the 'always pass' validator is set and incorrect values will pass thus. Setting the validator will make integer value restrictions work:binder.forField(field).withValidator(new IntegerRangeValidator("Some error message", -1000, 1000)).asRequired("Integer is required").bind(IntergerObject::getValue, IntergerObject::setValue);
I agree with both points - but as user it is not intuitive for me that I have to explicitly add a validator to the binder, because the field already has a "isInvalid" method that could be invoked by the binder and it makes me double my validation (on the field and binder level)
This is a missing feature that should be ported from Vaadin 8: https://github.com/vaadin/flow/issues/6803
@Legioth thanks! That explains why I'm used to this behavior.
As this is a missing feature - even when it exists in in Vaadin 8 - it is not a bug / regression but a new feature. Thus this cannot be prioritized using Warranty.
But I think it should be something that we forward-port to Vaadin 14 users quite easily, aye @mstahv ?
(keeping this issue open for now while the actual thing needed is in #6803 )
Thanks for the clarification @pleku. I had some hopes because of the old label ;)
Would love to see this "fixed / implemented". (Before we migrate our applications, going into production and get surprised)
That's a really unexpected "change / missing feature" when migration big applications that heavily rely on input validation done by the framework.
While #6803 is closed the components don't yet use the API so linking this issue to https://github.com/vaadin/components-team-tasks/issues/528
@pleku is there something I can do to fix this? Or is there any progress in this topic? I have no access to the linked issue
I've asked to transfer the issue or make that repository public but until something happens

Most helpful comment
This is a missing feature that should be ported from Vaadin 8: https://github.com/vaadin/flow/issues/6803