Customizing the behavior of Grails applications using the event model

A typical grails application throws events at key points in the application lifecycle, whether during the build process or when creating a single component, such as a domain class or controller. We can use these application events as extension points to create listeners to intercept them and respond to them using custom behavior. In addition to the traditional Web application lifecycle of HTTP requests and responses, Grails provides a large number of custom contact points that developers can use to process event models and give custom application behavior. These contact points include:

Events thrown during the build phase,

Startup and shutdown of Web applications,

Life cycle events for the Grails domain class.

Event handlers for Gant scripts first appeared in version 0.5 and were triggered during the execution of Grails targets and plug-in scripts. They are implemented in the Events.groovy script as a collection of closures (like anything else in grails) whose names begin with "event." When an "event" occurs in the Gant script, Grails invokes the appropriate event closure. Grails searches for these scripts in the following locations:

user_home/.grails/scripts--user-specific event handlers

project_home/scripts--apply a specific event handler

project_home/plugins/*/scripts--plug-in-specific event handlers

We can handle grails events at both the macro and micro levels. The macro level is the construction and application scope, while the micro-level is in the domain layer, and the domain class publishes events when interacting with the database. Scott Davis recently wrote an article about the Grails event model and how events that run through the Grails application lifecycle can help developers better customize the behavior of the application. Developers can extend the build process by creating a Events.groovy file and writing custom code in it without having to modify the standard grails scripts.

Build Event:

All of the build process steps between "grails Create-app" and "Grails Run-app" (or "grails war") throw events at key points. You can listen to these build events in your project by creating listeners. These events can also be used for post installation configuration and application upgrades. When you want to customize the script in grails_home/scripts (to throw custom events), Scott recommends that you copy the files to the scripts directory in your project so that these customized scripts are added to the source control system as well as other files.

Apply event:

In addition to building events, grails developers can capture application events to customize the application logic. Every time grails starts and stops, the boot files that are in the grails-app/conf directory will run. The init block in the file is invoked when the application is started, and the destroy block is invoked when the application stops. If you want to view debugging information when the Init and destroy events are triggered, type the following command to start Grails in interactive mode:

grails interactive"

An example of an extended application event is the addition of new records to the database at startup. Scott mentioned the use of Failsafe databases for inserts and deletions in Bootstrap.groovy to avoid duplicate records in the database. He also explains the behavior of the bootstrap script that is specific to the environment (development, test, or product). To use the Grailsutil class, import grails.util.GrailsUtil at the beginning of the script and invoke the static method Grailsutil.getenvironment () To determine which mode you are in (due to groovy's simplified getter syntax, this method invocation can be abbreviated to grailsutil.environment).

Domain Class Events:

This includes four event callbacks for CRUD operations: OnLoad, BeforeInsert, Befortupdate, and BeforeDelete, which are triggered when the database operation is performed.

OnLoad is invoked when the class is loaded from the database.

BeforeInsert is invoked before the Save () method executes.

BeforeUpdate is invoked before the update () method executes.

BeforeDelete is invoked before the delete () method executes.

Grails supports Gorm events and hibernate plug-ins to complement these events. The customization of the Gorm event, including the registration of events, triggers these events when deletes, inserts, and updates occur. The Hibernate event plug-in provides support for the domain model, which can be used to recall Hibernate event systems: AfterInsert, AfterUpdate, AfterDelete, Beforeload, Afterload, BeforeSave and Aftersave. Other domain-level events are the timestamp of the domain class. If you provide a pair of specially named fields (LastUpdated and DateCreated), Gorm automatically adds a timestamp to the class.

On other layers of the Web application, Grails provides Web stream execution events to manage the execution of web streams (from one state to another) and Ajax events (a specific JavaScript function is invoked if an event occurs in a Web application).

Grails also supports interception of automatic reload events, which can be used to monitor resource changes and reload resources when changes occur. This is why Grails can reload the application at run time.

View English Original:

Http://www.infoq.com/news/2008/09/grails-event-model