Re: [hibernate-dev] [Validator] Method level validation and cross parameter validator
On Feb 19, 2011, at 2:39 PM, Gunnar Morling wrote:
a scripting-based approach as described by Hardy is also the first idea which would come
to my mind.
Maybe @ScriptAssert could even be re-used for this (I also thought about providing
support for @ScriptAssert for property validation btw.). I'd like this idea as the
contract is tightly integrated with the annotated method (e.g. it would be part of the
method's JavaDoc etc.). As down-side there is the lack of type and refactoring
safety.
Another idea might be to support method-specific constraints similar to custom
class-level constraints which would provide more type safety:
Ideally, I think its best to have a generic method that allow to implement a @ScriptAssert
method (list like Class-level validation do today. Though the method proposed bellow is
quite interesting.
public class BookingService {
@ValidBooking
public Reservation book(Date startDate, Date endDate) {
//...
}
}
@ValidBooking would be a custom annotation type:
@Target({ METHOD })
@Retention(RUNTIME)
@MethodConstraint(validatedBy = {ValidBookingValidator.class})
public @interface ValidBooking{}
ValidBookingValidator would be a custom method constraint validator implementation with a
specific isValid() method:
public class ValidBookingValidator implements MethodValidator<ValidBooking> {
public void initialize(ValidBooking constraintAnnotation) {
}
public boolean isValid(Date startDate, Date endDate, ConstraintValidatorContext
constraintContext) {
return startDate.before(endDate);
}
}
Ideally this type would be generated by an annotation processor or similar. There might
be an isValid() method for each different method signature annotated with @ValidBooking
found by the generator.
Gunnar
2011/2/18 Hardy Ferentschik <hibernate(a)ferentschik.de>
On Fri, 18 Feb 2011 09:01:16 +0100, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
> Reading the Google design by contract work, I realized that we do not
> cover cross-parameter validation in method-level validation.
I assume you are talking about cofoja (http://code.google.com/p/cofoja),
right?
> //We want to make sure departure is after arrival.
> void book(Date arrival, Date departure);
>
> Any idea on ow best to address that?
Some ideas:
Introduce an equivalent to class level validators:
@DateParameterCheck
void book(Date arrival, Date departure);
@MyMethodValidator could contain a marker annotation so that we know that
we
have a method level validation. At first thought we would have to pass
object arrays
to the validator implementations. This is of course at odds with the type
safety approach
of BV.
Also if the method has a return value it is not directly clear by reading
the code
whether the return value would be validated or the parameters.
An alternative would be something similar to @ScriptAssert:
@ParameterCheck("arg[0].before(arg[1])")
void book(Date arrival, Date departure);
Gunnar already thought about naming parameters using @Named (HV-409),
maybe we could also do
something like:
@ParameterCheck("arrival.before(departure)")
void book(@Named("arrival") Date arrival, @Named("departure") Date
departure);
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev