Hi,
I was integrating the new Path API into Hibernate Validator and here are
some thoughts about it.
#1 Would it be worth to have a getLeafNode() method in the API. In many
cases you need that the leaf
and the only way to get to it at the moment is to use the Iterator. It
would also help for my second point
#2 TraversableResolver.isReachable and TraversableResolver.isCascadable
both take in their current version a
Node (the leaf) and a Path (the parent path) as parameter. Why not just
pass a Path instance. Together
with getLeafNode() we would almost have everything we need ;-)
#3 The Path API only specifies methods to iterate existing Path instances.
But at some stage one has to build
these path instances as well. Since the API does not have a
Path.addNode() (or similar) I am forced to use
the Hibernate Validator specific PathImpl all over the place. Wouldn't
it make sense to also add addNode()
to the interface?
Even though ErrorBuilder pattern in ConstraintValidatorContext is quite
nice and the API allows now for proper
validating of Maps, there are still some semantic gaps in the overall API.
For example, Validator.validateValue
and Validator.validateProperty both take a String repesentation of the
property to be validated. If the validation
fails the returned ConstraintValidationException contains however a Path
instance describing the property path.
This makes it quite hard to compare the input property with the property
in the ConstraintViolation.
I am not 100% convinced by this new Path API yet. As an internal data
structure yes, but if it should be part of the
official API - not sure.
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
