Groovy Mocking a Method That Exists on Object

In Groovy, the find method exists on Object. The find method is also an instance method on EntityManager which is commonly used in JPA to get an instance based on a database id. I was trying to create a Mock of EntityManager like:

def emMock = new MockFor(EntityManager)
emMock.demand.find { Class clazz, Object rquid -> return new Request(rqUID: rquid) }
def em = emMock.proxyDelegateInstance()

This gave me an error though:

groovy.lang.MissingMethodException: No signature of method: com.onelinefix.services.RequestRepositoryImplTest$_2_get_closure1.doCall() is applicable for argument types: (groovy.mock.interceptor.Demand) values: [groovy.mock.interceptor.Demand@a27ebd9]
Possible solutions: doCall(java.lang.Class, java.lang.Object), findAll(), findAll(), isCase(java.lang.Object), isCase(java.lang.Object)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:264) ~[groovy-all-1.8.6.jar:1.8.6]
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:877) ~[groovy-all-1.8.6.jar:1.8.6]
at groovy.lang.Closure.call(Closure.java:412) ~[groovy-all-1.8.6.jar:1.8.6]
at groovy.lang.Closure.call(Closure.java:425) ~[groovy-all-1.8.6.jar:1.8.6]

It ends up that find is a DefaultGroovyMethod that’s added to all Objects and this was causing the mock.demand to get confused because it thought I was trying to call the Object.find.

Luckily there is a workaround and that’s to use the ordinal argument for find.


emMock.demand.find(1) { Class clazz, Object rquid -> return new Request(rqUID: rquid) }

That’s enough of a change to invoke mock version instead of the DefaultGroovyMethod version.
Now if I only knew why….

Using Groovy AST to Add Common Properties to Grails Domain Classes

Groovy offers a lot of runtime meta-programming capabilities that allow you to add reusable functionality in a shared fashion. Grails plugins make use of this ability to enhance your project. One of the things that you can’t do with runtime meta-programming in Grails is to add persistent Hibernate properties to your domain classes. If you want to add a persistent property in a plugin (or otherwise using meta-programming) for your Grails project you have to make use of “compile-time” meta-programming. In Groovy this is done with AST Transformations.

(If you are unfamiliar with the concept of the Abstract Syntax Tree, see the Wikipedia article on Abstract Syntax Tree.)

AST Transformations are made up of two parts: (1) An annotation and (2) an ASTTransformation implementation. During compilation the Groovy compiler finds all of the Annotations and calls the ASTTransformation implementation for the annotation passing in information about.

To create your own Transformation you start by creating an Annotation. The key to the annotation working is that your annotation has to itself be annotated with @GroovyASTTransformationClass. The values passed to the GroovyASTTransformationClass define the Transformation that will be called on classes, methods or other code prior to it being compiled.

Example Annotation


package net.zorched.grails.effectivity;

import org.codehaus.groovy.transform.GroovyASTTransformationClass;
import java.lang.annotation.*;

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@GroovyASTTransformationClass({"net.zorched.grails.effectivity.EffectivizeASTTransformation"})
public @interface Effectivize {
}

Notice the reference to net.zorched.grails.effectivity.EffectivizeASTTransformation. That’s the important part because it defines the class that will be used to perform the transformation.

Example Transformation


package net.zorched.grails.effectivity;

import org.codehaus.groovy.ast.*;
import org.codehaus.groovy.ast.builder.AstBuilder;
import org.codehaus.groovy.ast.expr.*;
import org.codehaus.groovy.ast.stmt.*;
import org.codehaus.groovy.control.*;
import org.codehaus.groovy.transform.*;
import java.util.*;
import static org.springframework.asm.Opcodes.*;

@GroovyASTTransformation(phase = CompilePhase.CANONICALIZATION)
public class EffectivizeASTTransformation implements ASTTransformation {

// This is the main method to implement from ASTTransformation that is called by the compiler
public void visit(ASTNode[] nodes, SourceUnit sourceUnit) {
if (null == nodes) return;
if (null == nodes[0]) return;
if (null == nodes[1]) return;
if (!(nodes[0] instanceof AnnotationNode)) return;

ClassNode cNode = (ClassNode) nodes[1];
addProperty(cNode, "effectiveStart", Date.class, createGenerateStartMethodCall())
addProperty(cNode, "effectiveEnd", Date.class, createGenerateEndMethodCall())

}

// This method returns an expression that is used to initialize the newly created property
private Expression createGenerateStartMethodCall() {
return new ConstructorCallExpression(new ClassNode(Date.class), ArgumentListExpression.EMPTY_ARGUMENTS);
}

private Expression createGenerateEndMethodCall() {
return new MethodCallExpression(
new ConstructorCallExpression(new ClassNode(Date.class), ArgumentListExpression.EMPTY_ARGUMENTS),
"parse",
new ArgumentListExpression(new ConstantExpression("yyyy/MM/dd"), new ConstantExpression("2099/12/31")));
}

// This method adds a new property to the class. Groovy automatically handles adding the getters and setters so you
// don't have to create special methods for those
private void addProperty(ClassNode cNode, String propertyName, Class propertyType, Expression initialValue) {
FieldNode field = new FieldNode(
propertyName,
ACC_PRIVATE,
new ClassNode(propertyType),
new ClassNode(cNode.getClass()),
initialValue
);

cNode.addProperty(new PropertyNode(field, ACC_PUBLIC, null, null));
}
}

This example code gets called for each annotated class and adds two new Date properties called effectiveStart and effectiveEnd to it. Those properties are seen by Grails and Hibernate and will become persistent and behave the same as if you typed them directly in your Domain.

It’s a lot of work to add a simple property to a class, but if you’re looking to consistently add properties and constraints across many Grails Domain classes, this is the way to do it.

DRYing Grails Criteria Queries

When you’re writing code, Don’t Repeat Yourself. Now say that 5 times. *rimshot*

One of the things that I find myself repeating a lot of in many business apps is queries. It’s common to have a rule or filter that applies to many different cases. I came across such a situation recently and wanted to figure out a way to share that filter across many different queries. This is what I came up with for keeping those Criteria DRY.

To start with, I’ll use an example of an Article. This could be a blog post or a newspaper article. One of the rules of the system is that Articles need to be published before they are visible by end users. Because of this seemingly simple rule, every time we query for Articles, we will need to check the published flag. If you get a lot of queries, that ends up being a lot of repetition.

Here’s our example domain class:

package net.zorched.domain
class Article {
String name
String slug
String category

boolean published

static constraints = {
name(blank: false)
slug(nullable: true)
}
}

Now we need to add a query that will retrieve our domain instance by its slug (a slug is a publishing term for a short name given to an article, in the web world it has become a term often used for a search engine optimization technique that uses the title instead of an artificial ID). To perform that query we might write something like this on the Article class:

static getBySlug(String slug) {
withCriteria(uniqueResult:true) {
and {
eq('approved', true)
eq(' slug', slug)
}
}
}

We want to query based on the slug, but we also want to only allow a published Article to be shown. This would allow us to unpublish an article if necessary. Without the approved filter, if the link had gotten out, people could still view the article.

Next we decide we want to list all of the Articles in a particular category so we write something like this, again filtering by the approved flag.

static findAllByCategory(String category) {
withCriteria() {
and {
eq('approved', true)
eq('category', category)
}
}
}

Two simple examples like this might not be that big of a deal. But you can easily see how this would grow if you added more custom queries or if you had some more complicated filtering logic. Another common case would be if you had the same filter across many different domain objects. (What if the Article had attachments and comments all of which needed their own approval?) What you need is a way to share that logic among multiple withCriteria calls.

The trick to this is understanding how withCriteria and createCriteria work in GORM. They are both implemented using a custom class called HibernateCriteriaBuilder. That class invokes the closures that you pass to it on itself. Sounds confusing. Basically the elements in the closure of your criteria queries get executed as if the were called on an instance of HibernateCriteriaBuilder.

e.g.

withCriteria {
eq('a', 1)
like('b', '%foo%')
}

would be the equivalent of calling something like:


def builder = new HibernateCriteriaBuilder(...)
builder.eq('a', 1)
builder.like('b', '%foo%')

That little bit of knowledge allow you to reach into your meta programming bag of tricks and add new calls to the HibernateCriteriaBuilder. Every Class in groovy has a metaClass that is used to extend types of that Class. In this case we’ll add a Closure that will combine our criteria with other criteria like so:

HibernateCriteriaBuilder.metaClass.published = { Closure c ->
and {
eq('published', true)
c()
}
}

This ands together our eq call with all of the other parts of the passed in closure.
Now we can put the whole thing together into a domain class with a reusable filter.


package net.zorched.domain

import grails.orm.HibernateCriteriaBuilder

class Article {

static {
// monkey patch HibernateCriteriaBuilder to have a reusable 'published' filter
HibernateCriteriaBuilder.metaClass.published = { Closure c ->
and {
eq('published', true)
c()
}
}
}

String name
String slug
String category

boolean published
Date datePublished

def publish() {
published = true
datePublished = new Date()
}

static def createSlug(n) {
return n.replaceAll('[^A-Za-z0-9\\s]','')
.replaceAll('\\s','-')
.toLowerCase()
}

static findAllApprovedByCategory(String category) {
withCriteria {
published {
eq('category', category)
}
}
}

static getBySlug(String slug) {
withCriteria(uniqueResult:true) {
published {
eq(' slug', slug)
}
}
}

static constraints = {
name(blank: false)
datePublished(nullable: true)
slug(nullable: true)
}
}

And there you have it. Do you have any other techniques that can be used to DRY criteria?

Grails Embedded Classes ClassCastException

Using ORM tools allow you to map the data to a database independently of how your object model looks. Grails supports one-to-many and one-to-one relationships if you want to have the data in different table. But what about when you want to map a single table to multiple objects? In Grails a has a relationship where all the data is stored in a single table is defined by using the embedded syntax. (This creates a component in the Hibernate mapping world.)

An example of using the embedded syntax to create a compositional relationship:

class Person {
static embedded = ['address']

String name
int age
Address address = new Address()
}

class Address {
String street
String street2
String city
String state
String zip

static constraints = {
street2(nullable:true)
}
}

This is all great, but…
When you attempt to databind against the Person model including Address properties, you end up with an exception:

2009-04-17 20:36:10,058 [13260127@qtp2-0] ERROR errors.GrailsExceptionResolver – java.lang.ClassCastException: Address$__clinit__closure1
org.codehaus.groovy.runtime.InvokerInvocationException: java.lang.ClassCastException: Address$__clinit__closure1
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:92)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
at groovy.lang.Closure.call(Closure.java:279)
at groovy.lang.Closure.call(Closure.java:274)

It ends up there is a bug in Grails versions 1.0.4, 1.0.5 and 1.1 that is causing this. That bug is related to the constraints on the embedded class, in this case the Address class. Removing the constraints allows the object to be properly databound, with the obvious downside of lacking constraints.

I have filed a bug about this: GRAILS-4446. So hopefully it will be fixed soon. Hopefully if other people are having this problem they will help them out.

Update:
There is another workaround which is to declare the embedded class in its own file which makes it a first-class Domain object. When that’s done the constraints work as expected. The downside is that this means that a table will be created for the embedded domain class (and never used).

Update Table Data in Grails using Ajax Calls

Using Ajax for simple forms can offer users a very clean, simple and fast way to input data. I came across a situation recently where I was looking into replacing a document based workflow with an application. The documents themselves contained a series of different kinds of transactions that could have occurred. There were not a set number of any of the types and the user needed a simple way to enter many rows of data.

Grails offers some very easy to use simple Ajax controls. The formRemote tag has an update parameter that can be used to specify a DOM element to update after the form is submitted. This is Ajax in it’s simplest form. Submit some data and replace the contents of a DOM element with a partial-page update. This works well if you want to update a div for example. But what if you want to add a row to a table? In the standard update method, you would have to re-render the entire table contents. In many cases that will be fine, but I figured I could do better than that and just render the new row and add it to the table.

Defining Domain Classes

For this example we’ll start with some simple classes. An Account can have many Checks posted against it. There are no set number, so we define a hasMany relationship between the Account and the Checks.


class Account {
static transients = ['checksTotal']
static hasMany = [checks:Check]

Date date = new Date()

Double getChecksTotal() {
if (! checks)
return 0
return checks.inject(0) { current, check-> current + check.amount }
}

static mapping = {
checks joinTable: false
}
}

class Check {
String name
Double amount
String checkNumber
String reason
}

Creating a Controller

Next we need to create a Controller to mediate between our Domain and our Views. The Controller is setup to generate the default scaffold. We’ll end up overriding the show view to add a form on the page to easily post Checks to that Account. The action is the postCheck action. This is our Ajax action that will post the Check to the Account.


class AccountController {

def scaffold = true

def postCheck = {
def account = Account.get(params.id)
if(account) {
def check = new Check(params)
account.addToChecks(check)
if(! account.hasErrors() && account.save()) {
render template:'check', bean:check, var:'check'
}
}
}
}

The postCheck method calls the render method to render a template and return it as the Ajax response. This template contains the markup for a single Check row.

You can see the check template here:

${check?.name} ${check?.checkNumber} ${check?.reason}

Creating the Ajax Form

Now we need to add the form to our account/show.gsp so that we can call the AccountController.postCheck action. The example form is below. The thing to notice is that we’re not using the update parameter of the formRemote, but rather the onSuccess parameter. The update method tell the Ajax callback what element to replace but we can’t do that with a table. onSuccess on the other hand allows us to handle the returned values in our own way. Here’ we’re going to call the appendTableRow Javascript function to handle the response.

In this case I definitely don’t want to replace the entire node because the first row of my table is actually the form itself. This gives it a very nice look where the data is entered under the appropriate header and then immediately shows up as the following row when the user hits enter.

Checks


Name Check # Amount Reason


Luckily the appendTableRow function is made pretty easy by using the prototype APIs. The event returned to us is an HTML snippet, so in this case we just want to insert that snippet directly into the DOM which is accomplished with the insert prototype function.

function appendTableRow(tableId, e) {
$(tableId).down('tbody').down('tr').insert({after: e.responseText});
}

In the end you have a data table that allows for easy, fast updates with almost no hassle.

Custom Validators in Grails in a Single App

In my previous post I wrote about Building a Custom Validator in Grails using a Plugin. That’s a great way to build a reusable Constraint that will allow you to share your code among multiple projects. But often you only have one application that you are building, or a validator is a very domain specific thing that will only make sense in a single app.

Building the Constraint in a Single App

Please look at the previous post for the details of the Plugin.
As I mentioned in that post a plugin looks almost exactly like a Grails App. Just like in the plugin case, your grails app has a src/groovy and a src/java directory where you can put general code. In this case I wrote the Constraint in the src/groovy directory as I wanted to use the Groovy language and some of the fun dynamic techniques it offers.

Hook it into the App

Here’s the simple part. The goal, as we saw in the plugin example, is to register your custom Constraint with the Grails ConstrainedProperty class. I just took a guess on this one and it worked. Grails provides the
Config.groovy class to setup a bunch of things in your application. So all you need to do is add the ConstraintProperty configuration to your Config.groovy script and your application will have a new constraint:

Config.groovy

org.codehaus.groovy.grails.validation.ConstrainedProperty.registerNewConstraint(
PostalCodeConstraint.POSTAL_CODE_CONSTRAINT, PostalCodeConstraint.class)

Have fun building your own Constraints!

Build a Custom Validator in Grails with a Plugin

Grails is a really nice MVC framework inspired by Ruby on Rails. The difference is that Grails is built using Groovy and Java and leverages existing, well known frameworks as it’s foundation. It is essentially a fairly thin convention-over-configuration and integration layer on top of Spring and Hibernate. The documentation for common scenarios is pretty good, but once you get outside of the common cases it deteriorates pretty quickly. This is part of my contribution I guess.

Constraints and Validation

Grails has a fairly good set of built in constraints to use to validate your domain objects. This allows you to decorate your Domain with constraints which are validated prior to persisting the objects.

class Address {
String street
String city
String state

static constraints = {
street(nullable:true)
city(blank:false)
state(size:2..2)
}
}

You can find a comprehensive list of the built in validations on the Grails website. It includes the ability to create a custom validator for a domain class if the built in ones do not suffice. So you can write a validator inline to your domain object.


class Student {
String name
Calendar dateOfBirth
Calendar enrollmentDate

static constraints = {
name(blank:false)
dateOfBirth(blank:false, validator: { val, obj ->
// Ensure that the date of birth is before the enrollment date
return ! val.after(obj.enrollmentDate)
}))
}
}

This validator is just a closure, so you could write it external to the class and reuse it among many different domain classes. I was interested to know how to create a “first-class” validator though that looked and acted just like the built in ones.

Create a Plugin

Grails is essentially built as a series of plugins. Everything from Hibernate support to Service Injection is implemented as a Plugin. Because of this it obviously must have a strong plugin system that allows you to do almost anything. So I decided to look at using a plugin to create a shared validation.

So, first: Generate a plugin.
On the command line issue the command grails create-plugin MyApp. This will create a directory containing everything you need to construct a new plugin. The directory really looks like a mini Grails application. In fact you can run it exactly as a grails app which is great for testing.

This will create a src/ directory in the plugin as well. We can create our validator in there. You can create some directories under src/groovy or src/java to create a package. Use groovy or java depending on which language you want to use to implement your validator.

Create your Validator

Grails provides org.codehaus.groovy.grails.validation.AbstractConstraint as a simple base class to inherit from to get the basic functionality. Of course if you want to implement the whole thing yourself you just need to implement the interface
org.codehaus.groovy.grails.validation.Constraint. That would be a lot of work, so just inherit from the AbstractConstraint.

Here’s an example of a constraint used to validate a Postal Code (or zip code). This is a simple implementation that supports validating Canadian and US postal codes.

package net.zorched.validation

import org.codehaus.groovy.grails.validation.AbstractConstraint
import org.springframework.validation.Errors

class PostalCodeConstraint extends AbstractConstraint {

private static final String DEFAULT_NOT_POSTAL_CODE_MESSAGE_CODE = "default.not.postalCode.message";
public static final String POSTAL_CODE_CONSTRAINT = "postalCode";

private boolean postalCode;

private US = { postalCode->
postalCode ==~ /\d{5}/
}

private CA = { postalCode->
postalCode ==~ /[A-Z]\d[A-Z] \d[A-Z]\d/
}

public void setParameter(Object constraintParameter) {
if(!(constraintParameter instanceof Boolean))
throw new IllegalArgumentException("Parameter for constraint ["
+POSTAL_CODE_CONSTRAINT+"] of property ["
+constraintPropertyName+"] of class ["
+constraintOwningClass+"] must be a boolean value");

this.postalCode = ((Boolean)constraintParameter).booleanValue();
super.setParameter(constraintParameter);
}

protected void processValidate(Object target, Object propertyValue, Errors errors) {
if (! validPostalCode(target, propertyValue)) {
def args = (Object[]) [constraintPropertyName, constraintOwningClass,
propertyValue]
super.rejectValue(target, errors, DEFAULT_NOT_POSTAL_CODE_MESSAGE_CODE,
"not." + POSTAL_CODE_CONSTRAINT, args);
}
}

boolean supports(Class type) {
return type != null && String.class.isAssignableFrom(type);
}

String getName() {
return POSTAL_CODE_CONSTRAINT;
}

boolean validPostalCode(target, propertyValue) {
def country = "US"
if (target.metaClass.hasMetaProperty("country")) {
country = target.country
}
println country
this."$country"(propertyValue)
}
}

The name property is the key used to match your validator in your domain class to this Constraint instance.

class Address {
String street
String city
String state
String postalCode
String country = "US"

static constraints = {
street(nullable:true)
city(blank:false)
state(size:2..2)
postalCode(blank:false,postalCode:true)
}
}

Unit Test It

You’ll notice that I wrote the main algorithm for doing the validation as its own method. That will make it easy for me to write Unit Tests to confirm the functionality of my validator before I implement it in a domain class. So, now when someone comes back and wants to support Zip+4 in the US, I’ll can write a test, see that it fails and then fix my Constraint to support that case as well.


class PostalCodeConstraintTests extends GroovyTestCase {

void test_us_postal_code_succeeds_for_valid() {
def postalCodeConstraint = new PostalCodeConstraint()
def address = new Address(country:"US", postalCode:"53212")

assert postalCodeConstraint.validPostalCode(address, address.postalCode)
}

void test_us_postal_code_fails_for_canada() {
def postalCodeConstraint = new PostalCodeConstraint()
def address = new Address(country:"US", postalCode:"A1A 3E3")

assert ! postalCodeConstraint.validPostalCode(address, address.postalCode)
}

void test_ca_postal_code_succeeds_for_valid() {
def postalCodeConstraint = new PostalCodeConstraint()
def address = new Address(country:"CA", postalCode:"A1A 1D3")

assert postalCodeConstraint.validPostalCode(address, address.postalCode)
}
}

class Address {
String country
String postalCode
}

Wire It Into Grails

The only thing left to do is to register your Constraint so that Grails knows about it. When you created the plugin, grails generated a plugin “bootstrap” class for you. You can do that by registering your class with the ConstrainedProperty class provided by the Grails framework.


import net.zorched.validation.PostalCodeConstraint

import org.codehaus.groovy.grails.validation.ConstrainedProperty

class MyAppPlugin {
def version = 0.1
def author = "Geoff Lane"
def description = '''
This plugin adds specific functionality to the application for my app.
'''
def dependsOn = [:]
def loadAfter = ['controllers']

def doWithSpring = {
ConstrainedProperty.registerNewConstraint(
PostalCodeConstraint.POSTAL_CODE_CONSTRAINT,
PostalCodeConstraint.class);
}
}

ConstrainedProperty basically keeps a map of the constraint keys to the class type that implements the constraint.

Conclusion

Grails Plugins basically allow you to do anything that you might want to create an easily packaged piece of reusable functionality. I didn’t find a anything in the documentation about how to build validators like the built in ones, so I read a bunch of source code. Now you don’t have to, except for fun.


UPDATE: Please check out the Grails Custom Constraints plugin that automates all of this at http://grails.org/plugin/constraints

Coffee DSL in Groovy

I thought I’d follow up with my previous post with the Coffee Domain Specific Language in the Groovy Language.

This is really one of my first forays into Groovy, so it’s pretty rough. It’s really just a direct translation of the Ruby code and not what I would expect to be ‘idiomatic Groovy’. I’ll try and update this once I learn some more Groovy.


// CoffeeDSL.groovy
// This is the input from the user, likely read from a file
// or input through a user interface of some sort

CoffeeInput = "venti nonfat decaf whip latte"

class Coffee
{
def size
def whip
def caf
def type
def milk

public invokeMethod(name)
{
if (['venti', 'grande'].contains(name))
size = name
else if (['whip', 'nowhip'].contains(name))
whip = 'whip'.equals(name)
else if (['caf', 'decaf', 'halfcaf'].contains(name))
caf = name
else if (['regular', 'latte', 'cappachino'].contains(name))
type = name
else if (['milk', 'nonfat'].contains(name))
milk = name
else
throw new Exception("Unknown coffee informantion: ${name}.")
}

public order() {
def params = ''
if (milk)
params += milk + ' '
if (caf)
params += caf + ' '
if (whip)
params += 'whip '
println("Ordering coffee: ${size} ${params}${type}\n")
}

public load(input) {
// turn one line into multi-line "method calls"
def cleaned = input.split(/\s+/)
instance_eval(cleaned)
}

public instance_eval(methods) {
for (method in methods) {
this.invokeMethod(method)
}
}
}

// this is your code which loads the DSL input and executes it
coffee = new Coffee()
coffee.load(CoffeeInput) // load the user input
coffee.order() // submit the order

This isn’t even metaprogramming. You could do this in any language, Java, C#, whatever. Everyone talks about metaprogramming in Groovy, but I have not yet found a lot of information on it. Does anyone have any pointers?