11:35 p.m.
Hi all,
So a couple of months back I had a bean structure that I wanted to validate.
My selection was to use the validation framework.
I could after a while see that the framework specification, and hence the
implementations, fell short in several areas so my ideas below are based on
a live project.
1) Sometimes the contents of one bean depends on the contents of another
bean. The current specification does not in any way allow navigating the
bean tree despite this information being available internally of the
implementations. Also accessing the bean instances to get hold of the data
is not supported. The closest to a solution here was the Hibernate
implementation which did add a proprietary interface to extract the data
using PropertyNode. There is however a somewhat strange limitation in the
Hibernate implementation in that navigating the bean path does not allow
you to access the root bean, only the first children under the bean. This
means if the relevant data is located in another branch under the root node
there is no way to gain access to the data.
Solution: Allow full navigation up and down the bean structure and allow
accessing the bean instance to get hold of the data. A framework should not
impose limitations to what validation a user wants to do. This means make
the getValue method of Hibernate PropertyNode part of the standard and add
a getParent() to, for instance, Path.BeanNode to allow moving up the path.
2) Sometimes the bean structure can consist of lists with a large number of
elements. The current solution with index number makes it very cumbersome
to match a failed validation to whatever source of data you have (database,
xml file, input from webservice etc). In many cases an element (bean)
contains some data which can be considered as a "primary key" which makes
it easy to identify in the input data. To handle this I created a StringId
interface that the beans would implement and I then used this as output
when parsing the validation result. This however requires me to implement a
formatter for something that I think should be supported out of the box by
the validation specification.
Solution: Create an interface (of annotation, I have no strong feeling
about the actual implementation) that can be used to identify elements in a
list.
3) Sometimes the validation is situation dependent, for instance, the
expected bean contents depend on where the data is coming from or at what
point in time in the business process it is being validated. It would be
desirable to easily pass in a settings object in the validation method.
Solution: Extend ConstraintValidatorContext to allow passing user data or
extend the validation method to take an arbitrary Object given by the user.
I hope that I have been able to make my ideas clear and that there are not
too many errors in what I have written. It has been a while since I wrote
this code and I have since changed company so I can't check and verify that
I have gotten all details right.
Anders