Part 3 GORM

GORM

Domain classes are linked together through relationships; one-to-one, one-to-many, or many-to-many.

GORM is Grails' object relational mapping (ORM) implementation. Under the hood it uses Hibernate 3.

CRUD

Create

def p = new Person(name: "Fred", age: 40, lastVisit: new Date())
p.save()

The save method will persist your class to the database using the underlying Hibernate ORM layer.

Read

Grails transparently adds an implicit id property to your domain class which you can use for retrieval:

def p = Person.get(1)
assert 1 == p.id

Update

To update an instance, change some properties and then call save again:

def p = Person.get(1)
p.name = "Bob"
p.save()

Delete

To delete an instance use the delete method:

def p = Person.get(1)
p.delete()

Domain Modelling in GORM

To create a domain class you run the create-domain-class command as follows:

grails create-domain-class org.bookstore.Book

The result will be a class at grails-app/domain/org/bookstore/Book.groovy:

package org.bookstore

class Book {
}

This class will map automatically to a table in the database called book (the same name as the class). This behaviour is customizable through the ORM Domain Specific Language

Now that you have a domain class you can define its properties as Java types. For example:

package org.bookstore

class Book {
    String title
    Date releaseDate
    String ISBN
}

Each property is mapped to a column in the database, where the convention for column names is all lower case separated by underscores. For example releaseDate maps onto a column release_date. 

 

 

Part 2: Configuration

PART 2: CONFIGURATION

A. DataSource.groovy

Unaltered in the VRS case study.

The dbCreate property of the DataSource definition is important as it dictates what Grails should do at runtime with regards to automatically generating the database tables from GORM classes. The options are described in the DataSource section:

• create
• create-drop
• update
• validate
• no value

B. Introduction to BuildConfig.groovy and Config.groovy

BuildConfig.groovy, is for settings that are used when running Grails commands, such as compile, doc, etc. The second file, Config.groovy, is for settings that are used when your application is running. This means that Config.groovy is packaged with your application, but BuildConfig.groovy is not.

When multiple settings have the same base, nesting, or partial nesting can be used:

app {  

  email {
      host = 'mail.njit.edu'      desc = desc
      addr = 'vrs@njit.edu'      err {
         act = false         to = usrs.dev
         addr = 'Bugs <fix-it@njit.edu>'//       view = '/error'      }
   }

}

Accessing settings from your own application:

1. The settings in BuildConfig.groovy are only available from command scripts and can be accessed via the grailsSettings.config property like so:

target(default: "Example command") {

   def maxIterations = grailsSettings.config.myapp.iterations.max    …}

2. For those defined in Config.groovy, use the grailsApplication object, which is available as a variable in controllers and tag libraries:

class MyController {

def hello() {
        def recipient = grailsApplication.config.app.email.err.to

       render "Hello ${recipient}"
   }
}

C. Config.groovy

1. Externalised Configuration

• grails.config.locations - The location of properties files or addition Grails Config files that should be merged with main configuration.    e.g. 

grails.config.locations = ["file:${app.externPath}"]

where app.externPath is defined as:

externPath = (!local) ? app_extern_config_path : 'target/extern/my_config.groovy'

2. Other Runtime Settings

grails.serverURL - A string specifying the server URL portion of absolute links, including server name e.g. grails.serverURL="http://my.yourportal.com"

D. Per Environment Configuration

Grails supports the concept of per environment configuration. The Config.groovy, DataSource.groovy, and BootStrap.groovy files in the grails-app/conf directory can use per-environment configuration using the syntax provided by ConfigSlurper. eg.:

environments {
   test {
      app.email.err.act = true      app.dataSrc.logSql = false   }
   production {
      app.cas.url = 'https://webauth.njit.edu/idp/profile/cas'      .

      .
      app.dataSrc.action = 'update'      app.dataSrc.logSql = false   }
}

There are 3 preset environments - dev, prod, and test for development, production and test. For example to create a WAR for the test environment you wound run:

grails test war

Part1 : Introduction

Reference Documentation: http://docs.grails.org/2.3.8/guide/single.html#conf
Important sections:

1 <- does not mean whole section 1, it means read from 1 till 1.1 starts
2.[3,4,7,8,10,11] <- means 2.3, 2.4, 2.7, ...
4
4.1
4.1.1
4.2
4.3
4.3.[1,3,6] <- means 4.3.1, 4.3.3, ...
4.[4,5]
5
6
6.1
6.1.1
6.2
6.2.1
6.2.1.[1-4] <- means 6.2.1.1, 6.2.1.2, ..., 6.2.1.4
6.3
6.3.[1-5]
6.4
6.4.[1-5]
6.5
6.5.1
6.5.2
6.5.2.[1,4-9]
6.5.3
6.6
6.7
7
7.1
7.1.[1-4,6-9,11,12] - (7.1.6 (Intro), 7.1.7 (JSON))
7.2
7.2.1
7.2.1.[1,2,4]
7.2.2
7.2.2.[1-6]
7.2.[3,4]
7.3
7.3.[1-7]
7.4
7.4.[1,3,5,13]
7.6
7.6.[1-3]
8
8.2
10
10.[1,2,4,5]
11
11.1
11.1.1
11.[2-4]
13
13.[1-3]
14
14.[1-3]
14.5
14.5.1
17
19


Before creating Grails applications:


1. Download Grails framework (2.3.8), set GRAILS_HOME as a system variable, and add %GRAILS_HOME%\bin to your PATH. Set by step instructions can be found here.
-- Specific to case study VRS: add a system variable "local_machine" with the value of "1" or "true".
-- Specific to case study VRS: modify sample_my_config.groovy to my_config.groovy, change values as needed (banner tickets, usrname, pwd) and put in directory 'target/extern/my_config.groovy'.


Set up IDE (IntelliJ IDEA Ultimate for built in support).

2. Grails is a full stack framework and attempts to solve as many pieces of the web development puzzle through the core technology and its associated plugins. Included out the box are things like:

• An easy to use Object Relational Mapping (ORM) layer built on Hibernate

• An expressive view technology called Groovy Server Pages (GSP)

• A controller layer built on Spring MVC

• A command line scripting environment built on the Groovy-powered Gant

• An embedded Tomcat container which is configured for on the fly reloading

• Dependency injection with the inbuilt Spring container

• Support for internationalization (i18n) built on Spring's core MessageSource concept

• A transactional service layer built on Spring's transaction abstraction

3. Model - View - Controller Pattern

MVC pattern is a software architecture that encourages separation of concerns, such that:

Model - handles data representation and operations. For example, HangTag and Vehicle are part of the Model. Classes that represents entities (E.g. Vehicle) and business logic/functionalities (e.g. Register), collectively represent the model.

View - handles how data is viewed by the user. For example, the HTML code in register.gsp.

Controller - handle the code that links a user to the system. It receives request or events from the user, prepare data and invoke proper business logic, and then return the view that represents the result of user actions.


4. Grails uses Convention over Configuration, which means name and location of files is used instead of configuration, therefor it is important to be familiar with the directory structure:

• grails-app - top level directory for Groovy sources
• conf - Configuration sources.
• controllers - Web controllers - The C in MVC.
• domain - The application domain.
• i18n - Support for internationalization (i18n).
• services - The service layer.
• taglib - Tag libraries.
• utils - Grails specific utilities.
• views - Groovy Server Pages - The V in MVC.
• scripts - Gant scripts.
• src - Supporting sources
• groovy - Other Groovy sources
• java - Other Java sources
• test - Unit and integration tests.

5. Deploying an application 

Grails applications are deployed as Web Application Archives (WAR files), and Grails includes the war command for performing this task (runs in the production environment by default):

grails war

This will produce a WAR file under the target directory which can then be deployed as per your container's instructions.