Accord is an open-source (Apache-licensed) Scala validation library developed at Wix. It’s hosted on GitHub and you’re welcome to fork and dig into it; let us know what you think!
Why another validation library?
As we were transitioning from Java to Scala we’ve started hitting walls with the existing validation libraries, namely JSR 303 and Spring Validation. While there are a few validation frameworks written for Scala, notably scalaz with its validation features, after evaluating them we remained dissatisfied and ended up designing our own. If you’re interested, there’s more background and comparisons with existing frameworks on the project wiki at GitHub.
So what does it a look like?
A type validator is defined by providing a set of validation rules via the DSL:
Design goals
Accord was designed to satisfy four principal design goals:
Minimalistic: Provide the bare minimum functionality necessary to deal with the problem domain. Any extended functionality is delivered in a separate module and satisfies the same design goals.
Simple: Provide a very simple and lean API across all four categories of call sites (validator definition, combinator definition, validator execution and result processing).
Self-contained: Reduce or eliminate external dependencies entirely where possible.
Integrated: Provide extensions to integrate with common libraries and enable simple integration points where possible.
The first milestone release (0.1) already includes a substantial set of combinators (Accord’s terminology for discrete validation rules, e.g. IsEmpty or IsNotNull), a concise DSL for defining validators, result matches for ScalaTest and Specs², and integration facilities for Spring Validation.
Accord’s syntax is specifically designed to avoid user-specified strings in the API (this includes scala.Symbols). In practical terms, this means it doesn’t use reflection at runtime, and furthermore can automatically generate descriptions for expressions being validated. In the above example, you can see that RuleViolations can include both implicit (as in firstName) and explicit (as in lastName) descriptions; this feature enables extremely concise validation rules without sacrificing the legibility of the resulting violations.
Next up on this blog: Accord’s architecture. Stay tuned…
This post was written by Tomer Gabel
You can follow him on Twitter