3:18 a.m.
Hi Michael,
Great proposal! I like your scheme for capturing all types to be supported
and how you describe the validation routine.
Some questions/thoughts:
* Why is it that you use compareTo() over isAfter()/isBefore()? I reckon
the latter are not as widely supported amongst JSR 310 types?
* What are the shortcomings meant by "2.1.1. Working around limitations in
ConstraintValidator that prevent the above strategy"?
* What do you have in mind with regards to "2.4. "Simple" TemporalAmount
implementations support"?
* We need a way to expose the ClockProvider to ConstraintValidator
implementations (injection via CDI may be used, but BV must be usable
without CDI, too). Adding a new method
ConstraintValidatorContext#getClockProvider() seems the most obvious choice
(currently the RI provides
HibernateConstraintValidatorContext#getTimeProvider() for that purpose).
* Regarding Duration/Period, how about handling this separately? It seems
we could add this in a second step, allowing to align quickly on the
@Future/@Past additions and add support for it to the RI.
--Gunnar
2016-09-24 10:31 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org>:
Awesome, many thanks Michael! Going to look into the proposal asap.
--Gunnar
2016-09-23 22:08 GMT+02:00 Michael Nascimento <misterm(a)gmail.com>:
> Hi guys,
>
> I was finally able to write something before taking my flight this
> morning. Let me know what you think:
>
> https://github.com/sjmisterm/beanvalidation.org/blob/760cd54
> cb1f00bac1ae88d749d01cf80fe79f899/proposals/BVAL-496.adoc
>
> Regards,
> Michael
>
> On Fri, Sep 23, 2016 at 4:04 AM, John Hendrikx <hjohn(a)xs4all.nl> wrote:
> >
> >> > Another thing: If @Future and @Past support types like LocalDate,
> >> YearMonth and Year, should we perhaps enhance them to allow the
> user
> >> to specify that the "current" year/month/date should also be
valid?
> >>
> >> That's a very good point, too! This one has been specifically
> >> brought up with https://hibernate.atlassian.net/browse/BVAL-466
> >> <https://hibernate.atlassian.net/browse/BVAL-466>;. It seems
> sensible
> >> to add an annotation parameter for this given the support for these
> >> non-instant types. When looking at your example, I'd have a hard
> >> time though to reason the exact semantics of inclusive(). I hope we
> >> could find something more descriptive?
> >>
> >>
> >> I agree that "inclusive" isn't a good name. I'm open for
any ideas. ;-)
> >
> > Perhaps just provide annotations for their inverse.
> >
> > NotFuture/NotInFuture = past + now (past inclusive)
> > NotPast/NotInPast = future + now (future inclusive)
> >
> > Or perhaps a general modifying annotation, that can be applied to
> > everything to invert the matching logic:
> >
> > @Not
> >
> > Inverts the matching logic on this element.
> >
> > @Not @Past
> > @Not @Pattern("TRUE|FALSE") // hard to write without the @Not
> >
> > --John
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>