if( !book.save() ) {
   book.errors.each {
        println it
   }
}

In Grails 1.2 a feature was added to allow the option of forcing save to throw a grails.validation.ValidationException by using the failOnError argument.

try {
     book.save(failOnError:true)
} catch(ValidationException e) {
   // handle
}

If you prefer to make failing on validation errors the default, you can update Config.groovy in your Grails project to set the following property.

grails.gorm.failOnError=true

Thanks to Jeff Brown for reminding me of this when replying to a recent thread on the Grails user email list.

                          

It started last week with two Groovy related announcements. First, we were treated to Groovy 1.7 RC2 and found out that we have every reason to expect Groovy 1.7 GA before Christmas.

See: Groovy 1.7-RC-2 out there

Also, last week the Groovy-Eclipse team quietly released 2.0M2 of the Groovy Eclipse plug-in. They claim to have addressed over 100 issues, which includes a better inference engine, better refactoring support, task tag support, and content assist in GStrings. All in all, it looks like some nice improvements.

See: Groovy-Eclipse 2.0.0M2 New and Noteworthy

Then today there was an explosion of news all starting with the release of Spring Framework 3.0. There is a lot of good new stuff in there, and I’ll leave it to Juergen Hoeller to lay it all out for you.

See: Spring Framework 3.0 goes GA

This was followed very closely with the release of Grails 1.2 RC2 which includes the new Spring Framework 3.0 GA.

See: Grails 1.2-RC2 Release Notes

Finally, Guillaume Laforge posted an update on the modularity work that is being done as part of the Groovy 1.8 effort. This gist of this is to modularize Groovy into smaller pieces rather than having one, large groovy-all.jar distribution. Part of this effort will include replacing the current Ant based build with Gradle. This is a nice feather in the cap for Gradle.

See: Groovy 1.8 modularization

I am very excited to see what is to come in 2010 for the Groovy and Grails community. Judging by the activities of just the past month, there is a lot to be excited about for the year to come.

                          

As I recover from my Grails punch-drunk hangover and reflect on the seminar, there is one thing in particular that I keep coming back to – the Grails Framework plugin architecture. At the seminar, Jeff Brown ran a session on plugins during which he demonstrated how to create and use plugins as part of your Grails application development. I was impressed at how simple it is to build a Grails plugin, and how such a small amount of code can do so much for your application. Just in case everyone in the room was not already impressed, Jeff showed us his Clojure Plugin that allows the use of Clojure classes inside of any Grails application. Again, what was most impressive was how little code was required to enable such a powerful feature. In the end, we learned that nearly any library that can be invoked via a Java API can be integrated into Grails with a plugin.

Before the seminar, I already knew that Grails should be on everyone’s short list when considering web application development technologies. Powered by the Spring Framework, employing the simplicity of Groovy, adopting convention over configuration, and allowing you to leverage your existing investment in Java – it is hard not to love Grails. With the over 300 Grails Plugins, there was already plenty of opportunity to quickly extend Grails with any number of useful libraries. But what I am now convinced of is that the plugin architecture goes beyond being just useful and actually makes the Grails Framework one of the most compelling options to create web applications targeted at the Java Platform. Nearly any aspect of the framework can be extended or modified with the use of a plugin – Spring is the one thing that is not plug-able. Need to use a language that runs in the JVM but it isn’t Java, that isn’t a problem. Your investment in the Java Platform is protected by the fact that Grails will permit you to leverage your existing languages and libraries via plugins. And when the day comes, as it always does, to replace or update that library – install the new or updated plugin and you should hardly miss a beat. And while I’ve mostly talked about plugins for extensibility, let us not forget using plugins for code reuse. Plugins enable reuse between web apps with such ease that any battle hardened Java web developer will never want to think about extending a Struts Action or wiring a Spring Servlet context again as long as they live.