4: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
2:01 a.m.
Hi Anders,
Thanks a lot for getting in touch and sharing your experiences and suggestions.
Some questions below inline.
--Gunnar
2017-02-06 23:35 GMT+01:00 Anders Persson <thoroughsoft(a)gmail.com>:
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.
Can you give an example/use case for 1)? Is it that validation of bean
A depends on the state of a bean B referenced by A? If so, couldn't
you put this validation logic to B instead of A? And how do you
interact with PathNode here? Discussing a specific example would help
to grasp the full picture.
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.
Interesting one. Can you elaborate a bit on how you envision this
interface to look like and how it would be used?
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.
Do you want to apply different constraints in different "situations"?
If so, validation groups should be helpful.
If you want one constraint to behave situation-specific (not sure
whether it's a good idea), there is a solution if you work with a
container such as CDI or Spring: Inject the required context using the
correct scope (e.g. request-scoped) into ConstraintValidator
implementations.
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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
10:30 a.m.
Can you give an example/use case for 1)? Is it that validation of
bean
A depends on the state of a bean B referenced by A? If so, couldn't
you put this validation logic to B instead of A? And how do you
interact with PathNode here? Discussing a specific example would help
to grasp the full picture.
Unfortunately I have changed company since I implemented this so I will
have to rely on my shoddy memory...
The issue here was that based on a setting in bean B the result would be
different in bean A.
The bean structure was read from an XML structure using JAXB.
Bean A and bean B were not aware of each other, they were even residing in
different subtrees under the root node (meaning it would not help to put
the validation in bean B as suggested).
What I ended up having to do was to implement a full handling of parent
nodes in the beans just in order to be able to navigate up to the tree to
the root node to get hold of the relevant setting.
This I find is totally redundant work, especially when dealing with List
objects, since the validation is already keeping track of the path.
That is why I suggest that
a) the path should be fully navigatable upwards and allow access to the
actual instances
b) the path should be made available in the ConstraintValidatorContextthat
is passed to the validation method.
Interesting one. Can you elaborate a bit on how you envision this
interface to look like and how it would be used?
I did this in the simplest way possible.
I created an interface called StringId with one single method, String
getId().
This String would return whatever was considered the "primary key" of the
bean, thereby allowing an easy search in the XML structure for the
violation culprit.
When parsing and creating the validation failure I checked if the failing
object implemented StringId and if so I used that value, otherwise the
index.
This solution also mandates a possibility to access the actual bean
instance.
So the needs I found fully relied on the Hibernate implementation of the
validation framework.
I have a vague memory of it actually being Gunnar that implemented this
extra Path interface in Hibernat.
Do you want to apply different constraints in different
"situations"?
If so, validation groups should be helpful.
If you want one constraint to behave situation-specific (not sure
whether it's a good idea), there is a solution if you work with a
container such as CDI or Spring: Inject the required context using the
correct scope (e.g. request-scoped) into ConstraintValidator
implementations.
In my case the different behavior depended on a simple flag so I would
prefer that for really simple cases to just pass down this flag rather than
dealing with injections etc.
Passing down a Map with arbitrary content would also have offered a working
solution for the first problem since I could have passed down the root node
instead of navigating up the tree.
/Anders
On Tue, Feb 7, 2017 at 9:01 AM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> Hi Anders,
>
> Thanks a lot for getting in touch and sharing your experiences and
> suggestions.
>
> Some questions below inline.
>
> --Gunnar
>
> 2017-02-06 23:35 GMT+01:00 Anders Persson <thoroughsoft(a)gmail.com>:
> > 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.
>
Can you give an example/use case for 1)? Is it that validation of
bean
A depends on the state of a bean B referenced by A? If so, couldn't
you put this validation logic to B instead of A? And how do you
interact with PathNode here? Discussing a specific example would help
to grasp the full picture.
>
> >
> > 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.
>
Interesting one. Can you elaborate a bit on how you envision this
interface to look like and how it would be used?
>
> >
> > 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.
>
Do you want to apply different constraints in different
"situations"?
If so, validation groups should be helpful.
>
If you want one constraint to behave situation-specific (not sure
whether it's a good idea), there is a solution if you work with a
container such as CDI or Spring: Inject the required context using the
correct scope (e.g. request-scoped) into ConstraintValidator
implementations.
>
> >
> > 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
> >
> >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
2857
days inactive
2880
days old
beanvalidation-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Anders Persson -
Gunnar Morling