Hi,
> Do you think we should support the following?
>
> @DateInOrder
> void bookHotel(@NotNull @Valid Customer customer, Date from, Date to);
IMO that would be a useful feature. The following approaches came up
when discussing the idea earlier this year [1]:
1) A generic approach in the spirit of @ScriptAssert which would allow
to use script expressions in place like this:
@ParameterAssert(script="args[1].before(args[2])", lang="javascript")
void bookHotel(@NotNull @Valid Customer customer, Date from, Date to);
This could also be combined with a parameter naming approach (see HV-409 [2]):
@ParameterAssert(script="from.before(to)", lang="javascript")
void bookHotel(@NotNull @Valid Customer customer, @Named("from") Date
from, @Named("to") Date to);
2) An approach using dedicated constraints/validators:
@DateParameterCheck
void bookHotel(@NotNull @Valid Customer customer, Date from, Date to);
The validator for the constraint would get passed the parameter values
as array/list, maybe one would have a new interface
MethodConstraintValidator for this:
public class DateParameterCheckValidator implements
MethodConstraintValidator<DateParameterCheck> {
public void initialize(DateParameterCheck constraint) {}
public boolean isValid(Object[] parameterValues,
ConstraintValidatorContext context) {
return ((Date)parameterValues[1]).before((Date)parameterValues[2]);
}
}
As this is pretty un-safe, there also was the idea of supporting typed
validators like this:
public class DateParameterCheckValidator implements
MethodConstraintValidator<DateParameterCheck> {
public void initialize(DateParameterCheck constraint) {}
public boolean isValid(Customer customer, Date from, Date to,
ConstraintValidatorContext context) {
return from.before(to);
}
}
Such a validator would need an isValid() method for each method
annotated with the constraint. You found that "quite interesting" :)
Hardy also expressed some constraints that such a parameter constraint
couldn't be easily distinguished from a return value constraint.
> BTW I forgot but do we support Constructor validation?
IMO for the sake of completeness we should. This wouldn't add much
conceptual complexity or implementation efforts. Though probably not
all integration layers (such as Seam Validation/CDI) would use it
depending on their interception mechanism.
I guess it's best to continue the discussion at BVAL-232.
--Gunnar
[1] http://lists.jboss.org/pipermail/hibernate-dev/2011-February/005997.html
[2] http://opensource.atlassian.com/projects/hibernate/browse/HV-409
2011/7/8 George Gastaldi <gegasta...@gmail.com>:
> I think you should.
>
> 2011/7/8 Emmanuel Bernard <emman...@hibernate.org>
>
>> BTW I forgot but do we support Constructor validation?
>>
>> On 8 juil. 2011, at 16:02, Emmanuel Bernard wrote:
>>
>> > Do you think we should support the following?
>> >
>> > @DateInOrder
>> > void bookHotel(@NotNull @Valid Customer customer, Date from, Date to);
>> >
>> > ie like we have properly level and class level constraints, we could get
>> method level constraints receiving all the parameters and raising
>> constraints violations if necessary.
>> >
>> > Emmanuel
>> > _______________________________________________
>> > 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
>>
> _______________________________________________
> 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
