Home » JVM Languages » Scala » Introducing Accord: a sane validation library for Scala

About Yoav Abrahami

Yoav is the Chief Architect at Wix.com, working with developers and operations to build the company's future products as well as accelerating and improving development processes. Prior to joining Wix, Yoav was an Architect at Amdocs Cramer OSS division. Yoav holds a MS in Physics and a BS in Computer Science from the Tel Aviv University.

Introducing Accord: a sane validation library for Scala

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:

import com.wix.accord.dsl._    // Import the validator DSL

case class Person( firstName: String, lastName: String )
case class Classroom( teacher: Person, students: Seq[ Person ] )

implicit val personValidator = validator[ Person ] { p =>
  p.firstName is notEmpty                   // The expression being validated is resolved automatically, see below
  p.lastName as "last name" is notEmpty     // You can also explicitly describe the expression being validated
}

implicit val classValidator = validator[ Classroom ] { c =>
  c.teacher is valid        // Implicitly relies on personValidator!
  c.students.each is valid
  c.students have size > 0
}

You can then execute the validators freely and get the result back. A failure result includes its respective violations:

scala> val validPerson = Person( "Wernher", "von Braun" )
validPerson: Person = Person(Wernher,von Braun)

scala> validate( validPerson )
res0: com.wix.accord.Result = Success

scala> val invalidPerson = Person( "", "No First Name" )
invalidPerson: Person = Person(,No First Name)

scala> validate( invalidPerson )
res1: com.wix.accord.Result = Failure(List(RuleViolation(,must not be empty,firstName)))

scala> val explicitDescription = Person( "No Last Name", "" )
explicitDescription: Person = Person(No Last Name,)

scala> validate( explicitDescription )
res2: com.wix.accord.Result = Failure(List(RuleViolation(,must not be empty,last name)))

scala> val invalidClassroom = Classroom( Person( "Alfred", "Aho" ), Seq.empty )
invalidClassroom: Classroom = Classroom(Person(Alfred,Aho),List())

scala> validate( invalidClassroom )
res3: com.wix.accord.Result = Failure(List(RuleViolation(List(),has size 0, expected more than 0,students)))

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.
 

Reference: Introducing Accord: a sane validation library for Scala from our JCG partner Yoav Abrahami at the Wix IO blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*


× six = 36

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Do you want to know how to develop your skillset and become a ...

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!
Get ready to Rock!
To download the books, please verify your email address by following the instructions found on the email we just sent you.

THANK YOU!

Close