Original Source

DeveloperWorks has published the latest installment of Scott’s Mastering Grails series: The Grails Event Model. This article lays out the basis for event handling in Grails, both at the macro and micro levels. The macro level is build and application wide. Grails (and its huge library of plugins) usually publish events whenever a script runs or an artifact is changed, according to the plugins needs. You have the option to listen on those events and react accordingly. The micro level happens at the domain layer, where domain classes publish four events whenever they interact with the database.

Building a Web site is a study in event-driven, reactive development. Your application sits idle, anxiously waiting for the user to send in a request. It passes back the response and then goes back to sleep until the next call. In addition to the traditional Web life cycle of HTTP requests and responses, Grails provides a number of custom touch points where you can tap into the event model and provide behavior of your own.

In this article, you’ll discover the myriad of events being thrown in during the build process. You’ll customize the startup and shutdown of your application. And finally, you’ll explore the life cycle events of Grails domain classes.

Scott demonstrates in a few and simple steps how to plug into Grails’ events on the macro level (build), his recommendation is that once you get used to working with events you place your event handler scripts inside the project’s script directory, that way your customization will be saved in version control too. The other type of macro events are application events, whenever the application starts (init) or shutdowns (destroy). Grails includes a BootStrap.groovy script inside your project’s configuration, from there you can typically setup initial data required by the application (DomainBuilder is really handy in this situation), conversely you may delete any data saved. Or you could trigger a webservice call, it doesn’t have to be database related, the point is that you can put there whatever your application requires.

He finalizes with the micro level events, those fired by domain classes whenever they come in contact with the database, those events are: beforeInsert, befortUpdate, beforeDelete, and onLoad. The names should be self-explanatory, still Scott gives a good example of their usage.

Events throughout Grails can help you further customize the way your application behaves. You can extend the build process without modifying the standard Grails scripts by creating an Events.groovy file in the scripts directory. You can customize the startup and shutdown process by adding your own code to the init and destroy closures in the BootStrap.groovy file. And finally, adding closures like beforeInsert and beforeUpdate to your domain class allows you to add behavior such as timestamping and geocoding.

Tags: Grails, Scott Davis