Grails takes web development to the next level of abstraction. The fact that Java EE was not written with an application-level of abstraction led to the development and subsequent popularity of Java frameworks such as Spring, Hibernate, and so on. But most Java frameworks take a fragmented approach to web development.
You have to maintain the configuration for each layer. Grails embraces convention over configuration and wraps these powerful frameworks with a layer of abstraction via the Groovy language, thus providing a complete development platform that allows you to take full advantage of Java and the JVM. This chapter will reach under the covers of the Grails machine and look at its parts: its wheels and gears all moving in a coordinated motion, its workability, its leading-edge engine, and its underlying form. It will take a closer look at the interactions in the Grails ecosystem.
It will show how controllers handle, manage, direct, and orchestrate the logical flow of the application and how they handle requests, redirect requests, execute and delegate actions, or render views as the need arises. It will explore views and unravel how Grails uses SiteMesh, the page decoration framework, to give a consistent look to pages, as well as how views draw on Grails’ built-in tags and dynamic tags in its tag library to create well-formed markup and promote a clean separation of concerns. It’s quite a machine.
Convention over Configuration
Rather than configuration, Grails gives precedence to the convention. Convention over configuration, in simple terms, means writing configuration code only when you deviate from the convention. These ingenious conventions correspond to the directory structure; Grails brings into play the name and location of the files instead of relying on explicit configuration via the wiring of XML configuration files. This means if you create a class following the Grails conventions, Grails will wire it into Spring or treat it as a Hibernate entity.
By using the convention-over-configuration paradigm, Grails can envisage a component from its name and its location in the directory structure. One immediate consequence of this, other than speeding up application development, is that you have to configure a particular aspect of a component only when that configuration deviates from the standard.
Scaffolding
The Grails scaffolding generates an application’s CRUD functionality from the domain classes, at either runtime or development time. The generated application consists of the controller and GSP views associated with the domain class. The scaffolding also generates the database schema, including tables for each of the domain classes.
Object-Relational Mapping
Grails includes a powerful object-relational mapping (ORM) framework called Grails Object Relational Mapping (GORM). Like most ORM frameworks, GORM maps objects to relational databases; but unlike other ORM frameworks, GORM is based on a dynamic language. Therefore GORM can inject the CRUD methods right into the class without having to implement them or inherit them from persistent superclasses.
Summary
You saw how easy it is to develop a fully functional application using Grails scaffolding to do most of the work. You used static scaffolding as a learning tool, generating the controller and views for one domain class (Book). Then you navigated through the controller and saw that all the work in the controller is done in the actions. Then you learned the code for each action responsible for the corresponding view. Finally, you navigated through the views and saw how the views take advantage of the Grails tag libraries to promote a clean separation of concerns.
