Hi,
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:
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