Brent Baxter

I can’t begin to thank Scott Davis and Venkat Subramaniam enough for giving us a great start to the Philadelphia Groovy and Grails meet-up. It was great to see two seasoned speakers “on stage” at once, but even better two good friends that made the evening both interactive and informative. It was simply awesome.

It was great to have an active crowd as well, and I hope that everyone that attended was able to take away something from the evening. Scott and Venkat started with an agenda for the evening, but we quickly pulled them off track and wandered. I’m working from memory, but we roughly covered the following:

• Groovy is Java, except when it isn’t! Search for “Groovy the blue pill” or “Groovy the red pill” to see what that means.
• We saw several perfectly valid Java classes become elegantly simple Groovy classes
• Examples of Groovy metaprogramming and AST transformations (@Immutable, @Delegate and @Newify)
• What tools and IDEs might be considered for Groovy and Grails programming
• We learned that Venkat only uses a web browser that works with EMACS-like commands (it is Conkeror in case you are wondering)
• We were reminded of the evil lurking in Java with precision issues in double and float, and how Groovy avoided this issue

There were many more little bits of information, but suffice to say we covered a lot of ground. Thanks again to Scott and Venkat, and thanks to all that attended our first meet-up.

Please watch the meet-up group site for more information about our next meet-up.

Defining constraints in Grails domain classes is achieved quite simply with a static property defined directly in the domain class. For example, I can define a User domain class and its constraints as follows:

class User {
  String login
  String password
  String email
  Integer age

  static constraints = {
    login(size:5..15, blank:false, unique:true)
    password(size:5..15, blank:false)
    email(email:true, blank:false)
    age(min:18, nullable:false)
  }
}

Constraints are syntactically formatted as method calls with the name of the method matching the name of the property the constraint is to be associated with. The method parameters are named parameters specifying the constraint. On User we have defined a constraint for each property. This was my decision to constrain each property, there is not a requirement to name a constraint for all properties in a domain class.

So far so good, but now I want to verify my constraints work the way I expect. The easiest way to test constraints is as part of a unit test. Grails provides mocking support in unit tests, so to setup a mock domain class for constraint testing I would create the following test class.

import grails.test.*

class UserTests extends GrailsUnitTestCase {

  protected void setUp() {
    super.setUp()
    mockForConstraintsTests(User)
  }

  protected void tearDown() {
    super.tearDown()
  }

  void testValidation() {
    def user = new User(login:'jdoe', password:'passw0rd',email:'jdoe@foo.com',age:32)
    assertTrue user.validate()
  }
}

That is it. One item of note, I recently found out that it is possible to pass a list of property names to the valdiate() method indicating that the validation should only be run on those properties. For example, if I only want to validate the login and password properties on an instance of User then I would do the following.

user.validate(['login','password'])

This trick, however, does not work in unit tests as it appears the validate method provided by the mock does not accept any parameters. Still, this will come in handy when I know that I don’t have a fully populated domain POGO, but want to validate what I have. Say, for example, in a UI wizard where each step sets a partial set of properties on the domain class.