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 <hibern...@ferentschik.de>
> On Fri, 18 Feb 2011 09:01:16 +0100, Emmanuel Bernard
> <emman...@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
