When using buffered editing Vaadin 8.2 Binder isValid and validate implementation / documentation do not match
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 1.8k
- Forks
- 717
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 3
Description
8.2.0 buffered readBean/WriteBean pair works as expected using bean level withValidator, but there's still problem in binder.validate() and binder.isValid() methods.
If one uses validate() or isValid () directly, has not set bean with set bean but wants to use unbuffered editing (readBean/WriteBean - so handy that it's atomic now - thanks for it!) and there's bean level validators exception is thrown in validate() and isValid ().
Important part of stack trace looks like this (from 8.2.0.rc1)
Caused by: java.lang.IllegalStateException: Cannot validate binder: bean level validators have been configured but no bean is currently set
at com.vaadin.data.Binder.validate(Binder.java:1864) ~[vaadin-server-8.2.0.rc1.jar:8.2.0.rc1]
In addition documentation of Binder validate () and isValid () methods seem to be bit unclear. isValid () states that mentioned exception can be thrown ("IllegalStateException - if bean level validators have been configured and no bean is currently set"), validate () states that if setBean is not used bean level validators are ignored ("bean level validators are ignored if there is no bound bean "). It is unclear which is desired functionality, as it doesn't seems logical that these methods work differently.
It's possible to see error on validate() using this simple test app - just press "validate" or "isValid" at any point
https://github.com/nikkijuk/vaadin-playground/tree/master/vaadin8binder
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with Binder.validate() and Binder.isValid(), especially the behavior described around Binder.java:1864, and reproduce the issue with the linked vaadin8binder test app. Compare the method documentation with the observed bean-level-validator behavior and determine the intended consistent result; done means the implementation and documentation agree and the reported validation path no longer contradicts that behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100