holograph
commented
7 years ago Indeed Accord doesn't have any specific features for dates. You've actually run into three separate issues:
localDate.each(_.isAfter(LocalDate.now()) is true) will never work because it's really syntactically incorrect, you're basically trying to apply the result of each as a function and it was never designed to work this way.
The second option (introducing the local variable) won't work because:
- Free inline code is not supported within a validation block (see #6; it's an old issue but not trivial to support, and I've seen few if any compelling reasons to do so);
- You're actually mapping over the option, which evaluates to another option -- that's not how Accord works. More in a second.
Finally, the third option will technically work but doesn't quite express what you mean as I understand it. What you want is to say "p.dateOfBirth has a value, the following expression has to be true: ...". You can do this in one of two ways:
// Inline transform: simple, but may result in ugly descriptions:
p.dateOfBirth.map(_ isAfter LocalDate.now()).each is true
// ... which is why you should probably add a custom description:
p.dateOfBirth.map(_ isAfter LocalDate.now()).each as "Date of birth is in the future" is trueThe better solution would be to add proper validation rules, e.g.:
import com.wix.accord._
import com.wix.accord.ViolationBuilder._
// See http://wix.github.io/accord/dsl.html#custom-combinators
def aFutureDate: Matcher[LocalDate] =
new NullSafeValidator(_ isAfter LocalDate.now(), _ -> "is not a future date")
implicit val myValidator = validator[Person] { p =>
// ...
p.dateOfBirth.each is aFutureDate
}I'm definitely amenable to adding matchers on dates (built-in JVM types; JODA support will probably have to go in its own module), pull requests are most welcome :-)
buildreactive
It looks like Accord doesn't know about Java's date types:
Does not compile, so I thought I'd try this:
But this results in the following error:
I ended up doing this: