I have worked with Grails for some time now and thought I would share some of the common mistakes I have made early on. I also thought I could discuss some things that can make developing with Grails easier. Here is my short list of items:
Zero Turnaround Time
One of the convenient features of Grails is the ability to make a change and have that change be available immediately in your application. This is an obvious time saver and allows you to be more productive while developing your application. However, there are times when you will make major refactoring changes on the fly that the JVM cannot deal with. An example of this might be when you introduce something new in the middle of an existing class hierarchy. While it may appear that Grails is happy and your environment is sailing along you might see odd behaviour in the application and see some strange runtime exceptions along the way. What usually remedies this situation is instructing Grails to rebuild the internal structures in your application. This can be done by executing the following command and restarting your application:
# grails clean
Grails Console
One tool that you will want to keep in your Grails toolkit is the Grails console. This allows you to run a your application in an enviroment so you can experiment with code on the fly. One of the main reasons I do this is to try out my unit and integration code in the console before, or during, writing my tests. This is a fast way to get confidence that your test code will provide the results you want. And because you are doing this in the console you do not have to keep executing the grails test-app command to reinitialize the environment.
Since you have the full environment in the Grails console you can easily get references to your Spring beans and services. You are automatically provided a reference to the org.codehaus.groovy.grails.commons.spring.GrailsWebApplicationContext class with a variable named ctx. This allows you to do things like this in the Grails console:
def service = ctx.bookStoreService
def book = service.getCurrentBook()
println "The most recent book is ${book.name} by ${book.author}"
println book.dump()
You can see all of the defined beans that Grails is aware of like this:
ctx.beanDefinitionNames.sort().each {println it}
Manually Assigning Primary Keys
Most of the time your domain objects will have autogenerated primary key values for the id field. However, I ran into a situation where I needed to manually assign a primary keys for one of my domain objects. This took a little bit of trial and error to make this work. Here is how you do this correctly:
String id
static mapping = {
id generator:'assigned', column:'RECORD_ID', type:'string'
}
Also note that you must set the id manually outside of the object constructor on a separate line like this:
def obj = new MyDomainObject(name:'whatever')
obj.id = 'REC000001'
obj.save(flush:true)
Not like this:
def obj = new MyDomainObjects(name:'whatever', id:'REC000001')
obj.save(flush:true)
because the value will not be saved.
Manually Triggering Quartz Jobs in Grails
Grails has an excellent plugin for managing scheduled Quartz jobs. However, I had a situation where I wanted to manually schedule a job. I could not find this in the documentation so after poking around in the source I figured out how to do this using the following technique. First you have to define the job name and group like this:
class MyValidationJob {
def name = 'MyJobName'
def group = 'MyGroup'
// your executable job method here...
}
Then you can manually trigger the job like this:
// trigger the job manually by job name and group from your controller/service/whatever
def quartzScheduler // inject this in your class
quartzScheduler.triggerJob("MyJobName", "MyGroup")
Using Packages in the Grails
Grails provides a directory structure for your application components by convention similar to Rails. However, this can cause issues if you put your classes directly inside of these folders because they seen by Java in the default package. Using the default package can cause you issues when compiling your classes. Since we are using Groovy (and really Java) it is my opinion that you should add packages to your Groovy classes. I also think that modules in Ruby translate better than package structures at this point but we are stuck with Java constraints.
You can add packages to the provided services and domain folders and Grails will make Spring beans out of them. You just need to be careful not to use the same name for the bean twice. You just reference the bean by the name of the class. For example let's say you have a service called com.myco.service.validation.MyValidationService. Grails will expose this as a bean reference named myValidationService.
Base Classes with GORM
It is common practice that developers make a base domain class with common features of your subclassed domain objects. By defining an abstract class you can define common properties for your domain objects. There is a catch however. The GORM DSL allows you to define constraints and mappings blocks in these classes for validation purposes and defining ORM mappings respectively. The current problem is that if your subclasses have their own mappings and/or constraints defined they will override what is in your superclass instead of being merged with the superclass blocks. I am hoping that a future version of Grails addresses this issue (1.1 hopefully).
Unexpected NPEs
One of the earliest mistakes I made when working with Grails was generating NullPointerExceptions without much to decipher in the stack trace. The most common problem for me (which you will overcome quickly) was to make sure you validate your domain objects and handle the errors appropriately in your controllers. The errors object is automatically added to your domain objects and can be checked with the hasErrors method on those objects.
Viewing the Source of your GSP Files
This is just a quick tip that allows you to view the generated source of you GSP files. This is a simple as adding the 'showSource' parameter to your URL like this:
http://localhost/yourapp/yourController/list?sort=dateCreated&max=20&showSource
I guess I found out that I was not the only person who experiences this behavior when I attended Neal Ford's On the Lam from the Furniture Police presentation. There he explained how the right and left sides of your brain operate and how they contend for time. The right side of your brain is where your creative non-linear thoughts occur while the left side of you brain spends it's time with rational linear thought processes. It turns out that if you can occupy the left side of your brain with mundane white noise like sleeping, driving, showering, WoW, the wife, whatever...you free up time for your right brain to produce meaningful analytical abstractions without your left brain interfering.
How many times have you resolved an issue while you are in the process of explaining it to a coworker. Your own blabbering can shut down your right brain so your left brain can reason things out! Here is another cool technique that Neal Ford suggested which sounded bizarre at first to me but then made good sense (to me at least). He suggested putting a rubber duck on top of your monitor and when you get stuck you explain the issue to the duck. This is not a magic duck (I don't think). The point is you are freeing up your right brain to perform the tasks you are really interested in.
