Service w grails

Nie długi rozdział książki Definitive guide to grails, tym razem podejmuje tematykę serwisów.

Często stosowana w aplikacjach jest warstwa serwisów (service layer), która zawiera w sobie operacje biznesowe. Dzięki nim można wprowadzić warstwę abstrakcji oraz ograniczyć zależności pomiędzy warstwami mvc. Serwisów można używać dla:

• potrzeby scentralizowania logiki biznesowej w API
• przypadki użycia aplikacji operują na wielu klasach domenowych i operacji lepiej nie mieszać w jednym kontrolerze
• pewne procesy powinny być zhermetyzowane poza klasami domenowymi

Serwisy zazwyczaj mają wiele zależności(jdbc, orm).

Serwisy w grails nie rozszerzają żadnej klasy i znajdują się w grails-app/services/. Serwis tworzy się poleceniem create-service name. Do nazwy pliku zostaje dodana końcówka Service.

Serwisy domyślnie są singletonami. Dzięki korzystaniu ze springa mogą zostać wstrzyknięte(injected) do kontrolera (poprzez autowiring). Następuje to poprzez utworzenie pola o takiej nazwie jak serwis

class StoreController {
  def storeService

}

Aby wstrzyknąć serwis do innego należy postąpić tak samo. Nie należy tworzyć samemu instancji serwisów, tylko pozostawić to grails (traci się wtedy transakcyjność).
W serwisach są transakcje i są one zgodne z ACID:

• atomicity – cząsteczkowe
• consistency – spójne
• isolation – ilozacyjne, odseparowane
• durability – trwałe

Serwisy posiadają statyczną zmienną transactional, która ustawiona na true zapewnia transakcyjność. Można włączyć transakcyjność dla wybranych metod poprzez ustawienie transactional na false i wywołanie klasy domenowej z metodą withTransaction.

// turn off automatic transaction management
static transactional = false
void someServiceMethod() {
  Album.withTransaction {
    // everything in this closure is happening within a transaction
    // which will be committed when the closure completes
  }
}

Jeśli w przekazanym domknięciu wystąpi błąd nastąpi rollback transakcji.

Zakres serwisów

• prototype – nowy serwis jest tworzony zawsze jeśli jest wstrzyknięty do innej klasy
• request – nowy serwis na każdy request
• flash – nowy dla obecnego i następnego
• flow, conversation tak jak w grails web flow
• session – dla całej sesji dla danego użytkownika
• singleton – domyślny tylko jeden

Dla zasięgów flow, flash i conversation należy zaimplementować Serializable i mogą one być używane tylko z web flow. Deklaracja zasięgu odbywa się poprzez:

static scope = 'request'

Testowanie serwisów odbywa się poprzez testy integracyjne (dependency injection). Jeśli ma być test jednostkowy to trzeba utworzyć instancję (brak dependency injection).

Wystawianie serwisów odbywa się poprzez zmienną expose która jest listą

static expose = ['jmx', 'xfire']

Poprzez pluginy są dostępne różne możliwości jak np jmx, rmi, axis2 itd.

Parę słów o GORM

Jak do tej pory w książce Definitive guide to grails temat gorm pojawiał się chyba przez wszystkie rozdziały i teraz najwyższy czas o szczegółowe przyglądnięcie się temu zagadnieniu.

Każda klasa domenowa automatycznie jest rozszerzona o pewne metody, wspierające zapytania. Na przykład metoda get(id), zwraca daną encję lub null jeśli nie zostanie znaleziona.
getAll(id1, id2) – zwraca listę obiektów, może jako parametr przyjąć listę.
Te dwie metody sprawiają, że zwracany obiekty można modyfikować (persisted). Jeśli jest potrzebny obiekt tylko do odczytu (read-only) z pomocą przychodzi metoda read(id).

Zazwyczaj z bazy pobiera się jakąś listę elementów i służy do tego metoda list(), która zwraca wszystkie encje. Można wprowadzić dodatkowe parametry

• max – ilość zwracanych rekordów
• offset – wykorzystywane przy stronicowaniu
• sort – właściwość po której jest sortowanie
• order – kolejność sortowania

Często z metodą list() jest używana metoda count(), która zwraca ilość elementów.
Przykład użycia tych metod i parametrów:

// get all the albums; careful, there might be many!
def allAlbums = Album.list()
// get the ten most recently created albums
def topTen = Album.list(max:10, sort:'dateCreated', order:'desc')
// get the total number of albums
def totalAlbums = Album.count()

Dodatkowo są metody listOrderBy*, gdzie w miejsce * wstawia się nazwę pola, np

def allByDate = Album.listOrderByDateCreated()

Zapisywanie nowego i aktualizacja istniejącego rekordu odbywa się poprzez metodę save(). Hibernate, który znajduje się w GORM automatycznie rozpoznaje czy ma wykonać aktualizację czy zapis. Przy starszych silnikach bazodanowych, mogą się pojawić błędy ale można to obejść poprzez wymuszenie:

object.save(insert:true)

Usuwanie to metoda delete()

Zazwyczaj relacja jeden do wielu (one-to-many) to jest java.util.Set. Jeśli jest ważna kolejność to można użyć SortedSet. Trzeba podać wtedy regułę sortowania i może to być poprzez implementację Comparable.
Ewentualnie można dodać w właściwości mapping sortowanie (i wtedy będzie użyte dla każdego zapytania)

static mapping = {
sort "trackNumber"
}

Takie sortowanie może nie być potrzebne dla każdego zapytania a potrzebne dla zapytań jeśli jest powiązanie z innymi elementami.

static mapping = {
songs sort: "trackNumber"
}

Klasa jest w relacji 1-n z klasą Song, którą reprezentuje zbiór songs.

Zamiast setów, można używać listy i odwoływać się przez indeksy

List songs
println album.songs[0]

Także mapy są dozwolone, gdzie kluczem(indeksem) jest jakiś string.
Jako, że GORM zapewnia asocjacje to także posiada metody do zarządzania nimi addTo* i removeFrom*, które zwracają obiekt na którym zostały wywołane i dzięki temu wywołania można łączyć w łańcuchy

new Album(title:"Odelay",
artist:beck
year:1996)
.addToSongs(title:"Devil's Haircut", artist:beck, duration:342343)
.addToSongs(mySong)
...
.save()

Domyślna kaskadowość w GORMie zależy od właściwości belongsTo. Jeśli ta właściwość istnieje to operacje zapisu, updatu i usunięcia są kaskadowe. Jeśli jej nie ma to tylko zapis i aktualizacja są a usuwanie nie jest kaskadowe. Można nad tym mieć większa kontrolę poprzez

static mapping = {
songs cascade:'save-udpate'
}

Możliwe opcje takie jak w hibernate.

Dynamiczne findery są jednym z najpoteżniejszych konceptów GORM, trochę zbliżone do wcześniejszych listOrderBy*. Mogą zawierać w sobie logiczne zapytania jak And, Or, Not i wyglądają findBy*, gdzie w miejsce gwiazdki wchodzi pole z klasy z odpowiednim łączeniem np

findByTitleAndTime("title", 30)

W tych zapytaniach są dozwolone także inne operatory(operator, ilość parametrów, przykład):

• Between 2 Album.findByDateCreatedBetween(today-10,today)
• Equals 1 Album.findByTitleEquals(‘Aha Shake Heartbreak’)
• GreaterThan 1 Album.findByDateCreatedGreaterThan(lastMonth)
• GreaterThanOrEqual 1 Album.findByDateCreatedGreaterThanOrEqual(lastMonth)
• InList 1 Album.findByTitleInList(['Aha Shake Heartbreak', 'Odelay'])
• IsNull 0 Album.findByGenreIsNull()
• IsNotNull 0 Album.findByGenreIsNotNull()
• LessThan 1 Album.findByDateCreatedLessThan(lastMonth)
• LessThanOrEqual 1 Album.findByDateCreatedLessThanOrEqual(lastMonth)
• Like 1 Album.findByTitleLike(‘Shake’)
• NotEqual 1 Album.findByTitleNotEqual(‘Odelay”)

Podobnymi metodami dla findBy* są findByAll* (zwraca listę) i countBy*(ilość).
Dzięki dynamicznym finderom, można w aplikacji zrezygnować z warstwy DAO.

Kryteria są również potężnym narzędziem wykorzystującym buildery w groovy. Kryteria w GORM są bardziej rozbudowane niż w hibernate.
Przed użyciem kryteriów należy stworzyć instancję kryteriów dla danej klasy poprzez statyczną metodę createCriteria(). Po utworzeniu instancji można wywołać jedną z czterech metod z domknięciami:

• get - odnajduje unikalny element
• list - zwraca listę
• scroll - zwraca ScrollableResults dla zapytania
• count - ilość elementów

Najpowszechniejsze jest list

def c = Album.createCriteria()
def results = c.list {
  eq('genre', 'Alternative')
  between('dateCreated', new Date()-30, new Date())
}

Dostępne kryteria oparte są na klasie Restricions.
Jeśli jest asocjacja w klasie to również można użyć jej w kryteriach. Tworzy się to poprzez zbudowanie zagnieżdżonego kryterium gdzie nazwą jest właściwość w klasie

def criteria = Album.withCriteria {
  songs {
    ilike('title', '%Shake%')
  }
}

Istnieją zapytania przez przykład (query by example) gdzie jako parametr do finderów jest przekazywany obiekt:

def album = Album.find( new Album(title:'Odelay') )

GORM wspiera także zapytania w hql. Występują tutaj metody find, findAll i executeQuery. Dozwolone są kolejne parametry (positional parameters), paramery nazwane (named parameters)

// query for all albums
def allAlbums = Album.findAll('from com.g2one.gtunes.Album')
// query for an Album by title
def album = Album.find(
'from Album as a where a.title = ?',
['Odelay'])
// query for an Album by title
def album = Album.find(
'from Album as a where a.title = :theTitle',
[theTitle:'Odelay'])
// get all the songs
def songs = Album.executeQuery('select elements(b.songs) from Album as a')

Do stronicowania wykorzystuje się parametry offset i max. Można je przekazać w ostatnim argumencie dynamicznych finderów jako mapę:

def results = Album.findAllByGenre("Alternative", [max:10, offset:20])

W widoku służy do tego tag g:paginate, którego obowiązkowym atrybutem jest total, określający liczbę wszystkich encji. Domyślnie jest wywoływana aktualna akcja danego kontrolera, można to zmienić poprzez atrybuty contoller i action (tak jak w g:link). Również można określić nazwy przycisków dalej i wstecz poprzez atrybuty prev i next.

Wszystkie opcje konfiguracyjne w hibernate są dostępne w GORM. Wykorzystywane pliki to grails-app/conf/Config.groovy dla loggerów i grails-app/conf/DataSource.groovy. W tym pliku można zadeklarować blok hibernate i konfiguracja wygląda wtedy tak jak w plikach hibernate

hibernate {
  cache.use_second_level_cache=true
  cache.use_query_cache=true
  cache.provider_class='com.opensymphony.oscache.hibernate.OSCacheProvider'
}

Są dostępne zaawansowane mechanizmy zarządzania sesjami. Warto pamiętać o czyszczeniu sesji (mniejsze zużycie pamięci)

def index = {
  Album.withSession { session ->
    def allAlbums = Album.list()
    for(album in allAlbums) {
      def songs = Song.findAllByAlbum(album)
      // do something with the songs
      ...
      session.clear()
     }
  }
}

Występuje automatyczny zmiany (automatic flush) (Można zmienić na manual, commit i domyślny auto):

• kiedy zapytanie jest uruchomione
• bezpośrednio po skończeniu akcji kontrolera, jeśli nie został rzucony wyjątek
• przed skomitowaniem transakcji

Dlatego warto używać metody save(), ponieważ zapewnia ona walidacje i sprawia że obiekt jest tylko do odczytu jeśli pojawi się jakiś błąd. Jeśli nie jest naszym zamiarem aby zmieniać obiekt lepiej korzystać z metody read.

Można tworzyć bloki z transakcjami, rollbackami i zapisami po części operacji

def save = {
  Album.withTransaction { status ->
    def album = Album.get(params.id)
    album.title = "Changed Title"
    album.save(flush:true)
    def savepoint = status.createSavepoint()
...
// something goes wrong
    if(hasSomethingGoneWrong()) {
      status.rollbackToSavepoint(savepoint)
// do something else
...
  }
}

Domyślnie asocjacje są lazy. Można to zmienić poprzez

static mapping = {
artist fetch:'join'
}[/ourcecode]
lub w zapytaniu
[sourcecode language="java"]
def albums = Album.list(fetch:[artist:'join'])
for(album in albums) {
println album.artist.name
}

Także w kryteriach, hql i dynamicznych finderach można tego użyć.
Dostępne są 4 strategie cacheowania:

• read-only – tylko do odczytu
• nonstrict-read-write – malo i rzadkie operacje zapisu
• read-write – dużo i często, istnieje szansa zmian w tym samym czasie
• transactional - pełne zachowanie transakcyjne

class Album {
...
 static mapping {
  cache true
  songs cache:'read-only'
  }
}

Również można dać cacheowanie do zapytań poprzez parametr cache:true
Możliwa jest tabela dla hierarchii i tabela dla podklasy
Automatyczne wspierane są dateCreated i lastUpdate, wyłączenie tego to

class Album {
...
  static mapping = {
    autoTimestamp false
  }
}

Web flows w grails

Znowu lektura książki Definitive guide to grails przyśpieszyła. Tym razem bardzo długi rozdział, który przeczytałem bardzo szybko, o web flows w grails. Nie miałem wcześniej praktycznego do czynienia z przepływami (obieg i przepływ będę używał jako tłumaczenia flow). Wiedza jaką wyniosłem z tego rozdziału jest ogromna i żałuję, że wcześniej nie wziąłem się za grails. Jak Jacek Laskowski wielokrotnie wspominał nauka grails to także nauka wielu innych narzędzi i technologi. Ale do rzeczy.

Grails zapewnia wsparcie dla web flows opartego na spring web flow. Przepływy w grails są to serie stanów od rozpoczynające się od stanu początkowego a kończące na ostatnim, kolejno po sobie następujące. Niemożliwe jest wywołanie stanów nie po kolei. Spring Web Flow jest zaawansowaną maszyną stanów, flowExecutionKey i Id zdarzenia są przekazywane pomiędzy klientem a serwerem jako parametry w requescie, umożliwiając przejścia pomiędzy kolejnymi stanami.

W przeciwieństwie do Spring Web Flow, w grails nie jest wymagana żadna konfiguracja xml. Aby utworzyć obieg należy w kontrolerze utworzyć metodę, która kończy się na Flow (konwencja)

def shoppingCartFlow = {
...
}

Każdy przepływ ma swoje własne id, które ma nazwę taką jak ta metoda tylko, że bez słowa Flow (konwencja ponownie), czyli dla powyższego to będzie shoppingCart.

W przeciwieństwie do zwykłych akcji, akcja przepływu w ciele domknięcia nie definiują logiki a sekwencję stanów. Początkowym stanem, jest zawsze pierwszy stan zdefiniowany w przepływie.

def shoppingCartFlow = {
  showCart {
    on("checkout").to "enterPersonalDetails"
    on("continueShopping").to "displayCatalogue"
  }
...
}

Jeśli nastąpi zdarzenie checkout to wtedy przejdzie się do stanu enterPersonalDetails

Widok dla danego stanu znajduje się w grails-app/views/controllerName/flowId/state.gsp np
grails-app/views/store/shoppingCart/showCart.gsp

Stan końcowy to stan który nie przyjmuje parametrów lub jeden (w którym następuje przekierowanie do akcji lub innego obiegu).

Można zmienić nazwę widoku poprzez metodę render w stanie

showCart {
  render(view:"basket")
...
}

Istnieją stany akcji i stany widoku.
Stan widoku wstrzymuje wykonywanie obiegu w celu wyrenderowaniu widoku i interakcji z użytkownikiem. (np showCart wyżej ten z render jak i z on).
Stan akcji wykonuje blok kodu po, którym następuje przejście dalej. np

listAlbums {
  action {
    [ albumList:Album.list(max:10,sort:'dateCreated', order:'desc') ]
  }
  on("success").to "showCatalogue"
  on(Exception).to "handleError"
}

Obiegi posiadają swoje własne zasięgi i obiekty w nich muszą implementować java.io.Serializable:

• flash – przechowuje obiekty dla obecnego i następnego żądania.
• flow – przez cały czas przepływu, usuwając obieg kiedy zostanie osiągnięty ostatni stan.
• conversation – dla danego obiegu i jego podobiegów.

Istnieją dwie opcje wywołania stanu z linku i z wysłania formy (submitt).

Z linka, gdzie action to id przepływu

<g:link controller="store" action="shoppingCart">My Cart</g:link>

tutaj zawsze zostanie utworzony nowy przepływ, a jeśli chcemy wywołać jakieś zdarzenie to zostaje dodany atrybut event

<g:link controller="store" action="shoppingCart" event="checkout">Checkout</g:link>

Użycie zdarzenia w formie wygląda trochę inaczej, zdarzenie jest w atrybucie name submitButton

<g:form name="shoppingForm" url="[controller:'store', action:'shoppingCart']">
...
  <g:submitButton name="checkout" value="Checkout" />
  <g:submitButton name="continueShopping" value="Continue Shopping" />
</g:form>

Aby zwalidować formularz w przepływie, to można przekazać go do stanu akcji. Jednak zalecane jest wywołanie akcji przejścia (transition action). Jeśli transition action się nie powiedzie to przejście jest zatrzymywane a stan przywracany.

enterPersonalDetails {
  on("submit") {
    flow.person = new Person(params)
    flow.person.validate() ? success() : error()
  }.to "enterShipping"
  on("return").to "showCart"
}

Aby utworzyć podobieg należy użyć subflow(nazwaObieguFlow)

wrappingOptions {
  subflow(chooseGiftWrapFlow)
  on('giftWrapChosen') {
    flow.giftWrap = conversation.giftWrap
  }
  on('cancelGiftWrap'). to 'enterShippingAddress'
}

Zdarzeniami tutaj są wszystkie końcowe stany przepływu chooseGiftWrapFlow.

Istnieje w requescie właściwość xhr która określa czy żądanie jest ajaxowe.

W przepływach można zastosować CommandObject.

W obiegu można dynamicznie tworzyć przejścia pomiędzy stanami:

on('back').to {
  def view
  if(flow.genreRecommendations || flow.userRecomendations)
    view = "showRecommendations"
  else if(flow.lastAlbum.shippingAddress) {
    view = 'enterShipping'
  }
  else {
    view = 'requireHardCopy'
  }
return view
}

W różny sposób można zapisać przejścia między stanami

on('back').to 'enterShipping' // static String name
on('back').to { 'enterShipping' } // Groovy optional return
on('back').to { return 'enterShipping' } // Groovy explicit return

wszystkie powyżej są równoważne.

Poprzez assert można sprawdzić czy stan jest w odpowiednim stanie (masło maślane – ale chodzi o to czy nie pojawił się jakiś błąd np przy zapisie do bazy, pola są zwalidowane itp).

Testowanie przepływów jest wykonywane za pomocą klasy grails.test.WebFlowTestCase i są to testy integracyjne. Przy wygenerowaniu testu należy pamiętać o podmianie klasy z której nasza klasa dziedziczy (z GroovyTestCase na WebFlowTestCase).
Następnie należy zaimplementować abstrakcyjną metodę getFlow, która zwraca domknięcie, które reprezentuje web flow np

def controller = new StoreController()
def getFlow() {
  controller.buyFlow
}

Ajax i wyszukiwanie w grails

Kolejny rozdział książki Definitive guide to grails zajmuje się ajaxem w grails oraz wspomina o serwisach i pluginie searchable. Wobec tego można tą notkę połączyć z wpisem o autouzupełnianiu w grails.

Grails domyślnie wspiera prototype i Scriptaculous, ale poprzez system pluginów łatwo można dodać kolejne biblioteki ajaxowe.

Import biblioteki ajaxowej odbywa się poprzez dodanie w sekcji head strony gsp

<g:javascript library="prototype" />

Tagi ajaxowe posiadają atrybut before i after, i wtedy akcje w tym atrybucie są wywołane bezpośrednio przed i bezpośrednio po akcji ajaxowej (nawet jeśli pojawi się błąd w js).

• tworzy kotwicę bez przeładowni strony.
• rozszerzenie zwykłego forma na formy ajaxowe.
• pole tekstowe, które wysyła swoją wartość do serwera po zmianie tej wartości.

W można przechwytywać zdarzenia (handle events):

• onSuccess
• onFailure
• onLoaded
• onComplete
• onERROR_CODE

Serwisy są użyteczne przy scentralizowaniu logiki biznesowej, która jest dzielona przez różne warstwy. Domyślnie są one transakcyjne (statyczna zmienna – transactional).

W pliku grails-app/conf/spring/resources.groovy można ustawić cachewoanie poprzez Ehcache np

beans = {
  albumArtCache(org.springframework.cache.ehcache.EhCacheFactoryBean) {
    timeToLive = 300
  }
}

Do wyszukiwania warto używać pluginu searchable. Aby dodać opcję wyszukiwania należy w klasie domenowej dodać pole

static searchable = true

to jest wyszukiwanie dla wszystkich pól w danej domenie, aby ograniczyć do wybranych należy ustawić to np:

static searchable = [only: ['name']]

Ten plugin rozszerza klasy domenowe o kilka metod.

Autocomplete w grails

Dziś trochę praktyki w poznawaniu grails a mianowicie jak zrobić autouzupełnianie w formularzach grails. Jako, że funkcja automatycznego uzupełniania jest bardzo przydatna i do tego lubię ją najbardziej z wszelkich ajaxowych “udogodnień”, to przedstawię jak ją zaimplementować w grails.

Będę korzystał z pluginu grails-ui. Kilka screencastów pokazujących użycie tego plugina jest dostępnych na tej stronie.

Po zainstalowaniu pluginu, należy otworzyć stronę gsp na której chcemy dodać autouzupełnianie i w sekcji head wpisujemy:

<gui:resources components="autoComplete"/>

oraz tworzymy formatkę, w której będzie autocomplete

 <g:form action="searchUser">
    <gui:autoComplete id="searchUserAC"
                      controller="user"
                      action="usersAutoComplete"
                      resultName='users'
                      />
    <g:submitButton name='searchUser' value="SubmittAction"/>
    </g:form>

Autouzupełnianie będzie odnosiło się do kontrolera User i wywoływało akcję userAutoComplete.

A akcja userAutoComplete wygląda następująco:

import grails.converters.JSON

//some code

    def usersAutoComplete = {
        def users = User.findAllByLoginLike("${params.query}%")
        users = users.collect{
            [id:it.id, name:login]
        }

        def jsonUser = [
            users: users
        ]
        render jsonUser as JSON
    }

Wyświetlanie podpowiedzi odbywa się przy pomocy JSONa, gdzie wybrany element jest parą id(nie wyświetlane na formatce) i login(pokazywane). Oczywiście można dodać różne parametry do autouzupełniania jak np opóźnienie, minimalną długość wpisanego ciągu.

Internacjonalizacja w grails

Kolejny krótki rozdział książki Definitive guide to grails. Tym razem autorzy poruszają kwestię lokalizacji i jest to bardzo proste, jak wszystko do tej pory w grails.

Pliki z messagami lokalizacyjnymi znajdują się w grails-app/i18n/ (w netbeansie grails-app/MessageBundles/). To są zwykłe pliki properties z parą klucz-wartość.

Pobieranie wartości w kodzie odbywa się przy udziale klasy java.util.ResourceBundle.
Użycie tej klasy w kodzie java i groovy wygląda następująco:

// JavaMessages.java
import java.util.ResourceBundle;
public class JavaMessages {
  public static void main(String[] args) {
    ResourceBundle bundle = ResourceBundle.getBundle("messages");
    String appName = bundle.getString("app.name");
    System.out.println("application name is " + appName);
  }
}
// GroovyMessages.groovy
def messages = ResourceBundle.getBundle('messages')
def appName = messages.getString('app.name')
println "application name is ${appName}"

Strony gsp posiadają tag odpowiedzialny za lokalizację

<g:message code="gtunes.welcome"/>

gdzie code jest kluczem z pliku properties. Domyślnie grails korzysta z pliku properties, który reprezentuje lokalizację clienta (client’s locale)

Informację o języku można dodać do adresu a nie używać parametrów. Tutaj można znaleźć trochę o mapowaniu url. http://localhost:8080/gTunes/?lang=es można zastąpić http://localhost:8080/
gTunes/en/ poprzez mapowanie w pliku UrlMappings.groovy

static mappings = {
  "/store/$lang"(controller:'store')
}

Grails zapewnia również parametryzowanie messagów, przy pomocy klasy java.text.MessageFormat
Aby przekazać sparametryzowaną wartość w pliku properties należy w klamrach umieścić kolejny numer parametru dla danej wartości:

grail.message=To jest {0} wiadomość

Użycie tego w javie może wyglądać tak:

// JavaMessages.java
import java.util.ResourceBundle;
import java.text.MessageFormat;
public class JavaMessages {
  public static void main(String[] args) {
    ResourceBundle bundle = ResourceBundle.getBundle("messages");
    String countMessage = bundle.getString("grail.message");
    String message = MessageFormat.format(countMessage, 97);
    System.out.println("message: " + message);
  }
}

a w groovy

import java.text.MessageFormat
def bundle = ResourceBundle.getBundle('messages')
def countMessage = bundle.getString('grail.message')
def message = MessageFormat.format(countMessage, 97)
println "message: ${message}"

Również w tagu można przekazać parametry poprzez atrybut args=[].

<g:message code="grail.message"
args="[session.user.message?.size() ?: 0]"/>

Sparametryzowanych wiadomości, można użyć podczas wyświetlania komunikatów o walidacji.

Czasem z daną wiadomością należy wykonać coś innego niż pokazanie na stronie gsp. Grails również takie zachowanie wspiera poprzez beana messageSource, który jest instancją org.springframework.context.MessageSource
np w kontrolerze:

def messageSource
def index = {
  def msg = messageSource.getMessage('gtunes.my.music', null, Locale.ITALIAN)
// ...
}

Przyjazne linki i grails

Dziś trochę krótszy rozdział książki Definitive guide to grails ale jednak wbrew pozorom z dużą ilością ciekawych informacji. Nie tylko programiście mają łatwiej z grails ale także seo i pozycjonowanie może mieć pewne korzyści przy mapowaniu url i tworzeniu przyjaznych linków.

Domyślne mapowanie url w grails jest kolejnym przykładem konwencji ponad konfigurację. Można zastosować własne mapowanie, które posiada wiele opcji ale nie wymaga żadnych xml tylko troszkę kodu w groovy.

Domyślne mapowanie składa się z obowiązkowego kontrolera, opcjonalnej akcji (jak jej nie ma to jest wywoływana domyślna) i opcjonalnego id obiektu.
/controller/action/id

Definicja mapowania znajduje się w grails-app/conf/UrlMappings.groovy
Do mapowania można dodawać kolejne opcjonalne elementy, które muszą się pojawić na końcu wzorca. W domyślnym mapowaniu każdy element jest zmienną, która zawiera prefix – $. Można dodać statyczny tekst, który będzie częścią url:

static mappings = {
  "/showAlbum/$controller/$action?/$id?" {
    constraints {
      // apply constraints here
    }
  }
}

W tym przypadku url mapuje /showAlbum/album/list. Bez /showAlbum to będzie niepoprawny adres.

Z url można usunąć nazwę kontrolera i akcji mapując je na specyficzną nazwę:

static mappings = {
  "/showAlbum/$id" {
    controller = 'album'
    action = 'show'
  }
}

Teraz pokazywanie danego albumu będzie posiadało url: /showAlbum/jakieśId

Grails dostarcza także inną składnię tego samego mapowania

static mappings = {
  "/showAlbum/$id"(controller:'album', action:'show')
}

Grails zapewnia obsługę standardowych parametrów http, np url /showArtist?artistName=Rush może zostać obsłużony jeśli mapowanie będzie zdefiniowane

static mappings = {
"/showArtist"(controller:'artist', action:'show')
}

Nie trzeba nigdzie tutaj dodawać dodatkowych parametrów.

W taki sposób można dodać wiele parametrów do url ale przy większej ilości staje się on coraz bardziej brzydki i nieczytelny. Grails zapewnia, że zamiast takiego mapowania url z parametrami /showArtist?artistName=Rush można wartość dodać jako część url /showArtist/Rush, wystarczy tylko zmapować ten parametr:

static mappings = {
  "/showArtist/$artistName"(controller:'artist', action:'show')
}

Taki parametr można przekazać w kontrolerze za pomocą params.parametrName

def artist = Artist.findByName(params.artistName)

Można dodawać dodatkowe parametry, które nie będą pokazane w url:

static mappings = {
  "/showArtist/$artistName"(controller:'artist', action:'show') {
    format = 'simple'
  }
}

Tutaj istnieje dodatkowy parametr format o wartości simple.

W url można zmapować wzorzec do określonego widoku.

static mappings = {
  "/"(view:'/welcome')
}

Tutaj jest mapowany root aplikacji (/) do widoku grails-app/views/welcome.gsp

Także można zmapować do widoku w konkretnym kontrolerze

static mappings = {
  "/find"(view:'query', controller:'search')
}

Tutaj url /find jest zmapowany do widoku query w kontrolerze search. W takim przypadku nie jest wywoływana żadna akcja kontrolera, tylko zostaje określona lokalizacja odpowiedniej strony gsp.

W mapowaniu url można używać ograniczeń podobnych a właściwe prawie takich samych (drobna różnica o czym za chwilę) jak ograniczenia w klasach domenowych.

static mappings = {
  "/grailsblogs/$year/$month/$day/$entry_name?" {
    controller = 'blog'
    action = 'display'
    constraints {
      year matches: /[0-9]{4}/
      month matches: /[0-9]{2}/
      day matches: /[0-9]{2}/
    }
  }
}

Parametr year musi być czterocyfrowym numerem, month i day dwu. Ograniczenia muszą się pojawić w takiej kolejności jak przekazane parametry.

Różnica między ograniczeniem w klasie domenowej a w mapowaniu url jest taka, że w klasie domenowej jest to pole którego przypisaną wartością jest domknięcie a w mapowaniu jest to metoda, która jako parametr przekazuje domknięcie. Czyli w constraincie w mapowaniu url nie jest potrzebny znak równości (właściwie przypisania =) a przy klasie domenowej on musi być.

W mapowaniu url w grails dozwolone są wildcardy, ich symbolem jest gwiazdka(*).

static mappings = {
  "/images/*.jpg"(controller:'image')
}

To mapowanie odnosi się do dowolnego pliku w katalogu image, który kończy się na jpg. Jeśli jest potrzeba aby odnosiło się do dowolnej ilości podkatalogów należy użyć podwójnej gwiazdki (**)

static mappings = {
  "/images/**.jpg"(controller:'image')
}

Można mapować do akcji HTTP

static mappings = {
  "/artist/$artistName" {
    controller = 'artist'
    action = [GET: 'show',
                PUT: 'update',
                POST: 'save',
                DELETE: 'delete']
  }
}

A także do kodów odpowiedzi HTTP

static mappings = {
  "404"(controller:'store')
}

Tag również potrafi obsługiwać mapowanie url. O ile nic nie zostanie zmienione w pliku UrlMappings.groovy to jego użycie w formie:

<g:link action='show'
  controller='artist'
  id="${artist.id}">${artist.name}</g:link>

utworzy link /artist/show/jakieśId
A jeśli chcemy aby ten tag obsługiwał przyjazne linki, które zdefiniujemy w pliku np w ten sposób:

static mappings = {
"/showArtist/$artistName"(controller:'artist', action:'show')
}

to wywołanie tagu nie wiele się różni od poprzedniego wywołania:

<g:link action='show'
  controller='artist'
  params="[artistName:${artist.name.replaceAll(' ', '_')}">${artist.name}
</g:link>

i tutaj do mapy parametrów jest przekazywany parametr artistName, na którego wartości została dokonana operacja zamiany stringów.

Można tworzyć własne klasy mapujące, które znajdują się w grails-app/conf/ i kończą się UrlMappings (konwencja). Ich struktura jest taka sama jak domyślnego pliku mapowania.

Chyba to nie będzie niespodzianką ale grails pozwala testować mapowanie url. Podstawową klasą jest grails.test.GrailsUrlMappingsTestCase a testy są integracyjne a nie jednostkowe jak dotychczas.

Widok w grails

Jako, że grails jest frameworkiem mvc i opisałem model(klasy domenowe ), controller(kontrolery ), to najwyższa pora na view. Wpis oparty na książce Definitive guide to grails.

Dlaczego warto używać gsp:

• Aby wykorzystać zalety groovy, technologia widoku musi mieć wiedzę o groovy
• Lepszy język wyrażeń (GPath, przeciążone operatory)
• GString, wyrażenia regularne, operacje na listach i mapach

Atrybuty zasięgu takie jak w kontrolerach.
out – Writer w responsie

Gsp jest podobne do jsp i wiele obiektów z jsp jest dostępnych w gsp. GSP jest bardziej zwinny (agile) niż jsp.

Dyrektywy <%@ %>

<%@ page contentType="text/xml; charset=UTF-8" %>

Także importy w dyrektywach są rzadziej używane z racji tego groovy domyślnie importuje wiele pakietów.

Skryptlety <% %>, dla zgodności z jsp, należy używać tagów gsp.

Wyrażenia <%= %>
<%= "print me!" %> równoznaczne z <% out << "print me!" %>

Strony gsp można traktować jako jeden wielki GString.

<c:out value="${album.title}" />

i to samo w gsp

${album.title}

Strony gsp posiadają swoje własne wbudowane tagi, których nie trzeba importować. Przestrzenią nazw dla nich jest g. Można importować tagi jsp.

Wbudowane tagi gsp.
Tagi gsp są domknięciami.
Ustawienie wartości tagiem g:set

<g:set var="albumTitle" value="${album.title}" />

var to zmienna a value przypisana wartość. Można dodać scope dla zakresu, np

<g:set scope="session" var="user" value="${user}" />

Tagi z logiką<g:if>, <g:elseif> i <g:else> odpowiadają za sprawdzenie warunków. Tagi <g:if> i <g:elseif> posiadają atrybut test, który może być w języku wyrażeń (expression language) i w nim jest warunek.

<g:if test="${album?.year < 1980 && album?.genre == 'Rock'}">
  Classic rock
</g:if>
<g:elseif test="${album?.year >= 1980 && album?.genre == 'Rock'}">
 Modern Rock
</g:elseif>
<g:else>
  Other
</g:else>

Konstrukcja album?.year zostanie wywołana wtedy gdy album jest różny od null. Null w stronach gsp jest wyświetlany jako pusty string.

Tagi iterujące

<g:each in="${album.songs?}">
  <span class="tag">${it.title}</span>
</g:each>

Jeśli zostanie użyty ? w wyrażeniu to jeśli będzie null nie będzie iterowane. Można nadać nazwę zmiennej aby nie używać domyślnej nazwy – it. Dokonuje się tego poprzez var.

<g:while> jak pętla while

<g:set var="i" expr="${album.songs?.size()}" />
<g:while test="${i > 0}">
<g:set var="i" expr="${i-1}" />
</g:while>

odpowiednik tego w groovy to

while(i > 0) i=i-1

Dodatkowo tagi iterujące wspierają operacje na listach takie jak collect, findAll zapewniają obsługę GPath.

<ol>
<g:collect in="${albums}" expr="${it.title}">
	<li>${it}</li>
</g:collect></ol>

jest równoznaczne z

<ol>
<g:each in="${albums.title}" >
	<li>${it}</li>
</g:each></ol>

przykład z findAll

<g:findAll in="${albums}" expr="${it.songs?.title.contains('Love')}">
	<li>
${it.title}</li>
</g:findAll>

Dynamiczne tagi

Można ich używać tak samo jak tagów wbudowanych dodatkowo mogą być wywołane jako metody w skryptletach lub wyrażeniach GString.

<!-- With a regular tag -->
<a href="<g:createLink action="list" />">A dynamic link</a>
<!-- As a method call -->
<a href="${createLink(action:'list')}">A dynamic link</a>

Ciało taga może być przekazane jako ostatni argument w metodzie

Tagi linkujące:
<g:link>  linkuje do jakiś akcji, wspiera atrybuty
-controller – nazwa kontrolera
-action – nazwa akcji
-id – id doklejane do końca URI
-params – parametry przekazywane jako mapa.

Co najmniej jeden z atrybutów controller/action jest wymagany. Jeśli podany jest tylko controller bez action zostanie wywołana domyślna akcja danego kontrolera. Jeśli jest action bez kontrolera to zostanie wywołana akcja w obecnie wykonywanym kontrolerze. wspiera również wszystkie atrybuty htmlowego tagu anchor.

<g:link controller="album" action="list">List Albums</g:link>
<g:link action="show" id="1">Show album with id 1</g:link>

przykład z przekazaniem parametrów

<g:link controller="album"
action="list"
params="[max:10,order:'title']">pokazuje pierwsze 10 sortowane po tytule</g:link>

inne tagi linkujące to <g:createLink> podobne działanie jak tylko, że tworzony jest link a nie kotwica.

<g:createLinkTo> można linkować do zasobów w kontekście aplikacji. Najczęściej linkowanie do obrazków, arkuszy styli.

	<link rel="stylesheet" href="${createLinkTo(dir:'css',file:'main.css')}"></link>

Formularze

<g:form action="register" name="registerForm">
</g:form>

<g:textField> równoznaczny z <input type=”text”>.
checkbox

<g:checkBox name="aBooleanValue" value="${true}" />

Radio są grupowane i muszą posiadać taką samą nazwę aby były połączone.

<g:radio name="myGroup" value="1" checked="${someValue == 1}" /> Radio 1

<g:radio name="myGroup" value="2" checked="${someValue == 2}" /> Radio 2

select

<g:select name="genre" from="${['Rock', 'Blues', 'Jazz']}"
value="${album.genre}" />

posiada 2 ciekawe atrybuty optionKey i optionValue co pokazuje przykład

<g:select name="album.id" from="${Album.list()}"
optionKey="id" optionValue="title"/>

jest równoznaczne z

<select name="album.id">
<option value="1">Undertow</option>
...
</select>

Podobne tagi to <g:currencySelect>, <g:localeSelect> i <g:timeZoneSelect>

daty

<g:datePicker name="myDate" value="${new Date()}" precision="day" />

gdzie precision określa precyzję daty. Bez tego atrybutu pokazywane jest ze szczegółowością co do sekundy. dataPicker jest instancją java.util.Date.

<g:hasErrors> czy są błędy atrybuty, które mogą się pojawić to bean, field, model.
<g:eachError> iterowanie po błędach.

Domyślne komunikaty dla błędów znajdują się w grails-app/i18n/message.properties

Można wyświetlać błędy jako listę.

<g:renderErrors bean="${album}" as="list" />

Stronicowanie odbywa się za pomocą tagu , domyślna ilość to 10 rekordów na stronę, obowiązkowym polem jest total, opis atrybutów tego tagu.

Szablony gsp (gsp templates) są specjalnym plikiem gsp zawierającym tylko kawałek strony, który może być wykorzystany na wielu stronach. W szablonach mogą pojawić się wszystkie rzeczy jak w zwykłych stronach gsp. Specyficzną cechą szablonów jest ich nazwa, która zaczyna się podkreśleniem(_). Przykładowa ścieżka to grails-app/views/album/_albumList.gsp

Aby dołączyć szablon do strony należy użyć tagu render z atrybutem template, podczas jego użycia znika z niego podkreślenie w nazwie

<g:render template="/album/albumList"/>

Aby przekazać dane do szablonu należy użyć atrybuty model, który jest mapą

<g:render template="/album/albumList"
model="[albums: top5Albums]"/>

Mapa jest zdefiniowana w akcji danego kontrolera

[top5Albums: Album.list(max:5, sort:"dateCreated", order:"desc")]

Tworzenia własnych tagów gsp.
Można podzielić na 3 kategorie:

• proste tagi (simple tags) – tagi posiadają atrybuty bez ciała
• tagi logiczne (logical tags) – ciało jest wykonywane pod pewnym warunkiem
• tagi iteracyjne (iterative tags) – ciało jest wykonywane conajmniej jeden raz

Tagi definiuje się w klasie, która kończy się TagLib i znajduje się w grails-app/taglib. Aby utworzyć taką klasę należy użyć polecenia grails create-taglib. Własne tagi (custom tags) pełnią role helperów dla widoku.
Tag jest domknięciem, które posiada 2 parametry: atrybuty tagu jako mapa i ciało jako domknięcie.

def repeat = { attrs, body ->
  attrs.times?.toInteger().times { n ->
    body(n)
  }
}

a użycie tego to

<g:repeat times="3">
  Hello number ${it}
</g:repeat>

Domyślną przestrzenią nazw dla własnych tagów jest g, można ustawić własną poprzez

static namespace = 'someNamespace'

Własne tagi można testować. Podstawowa klasa to grails.test.TagLibUnitTestCase

Kontrolery w grails

Duża porcja wiedzy o kontrolerach na podstawie książki Definitive guide to grails.

Kontrolery w grails są odpowiedzialne za przechwytywanie requstów aplikacji i decydowanie co z nimi można zrobić:

• wykonać inna akcję kontrolera (nie koniecznie tego samego)
• wyświetlić widok
• wyświetlić informację bezpośrednio w responsie

Klasy z kontrolerami znajdują się w katalogu controllers. Każda klasa musi się kończyć na Controller (konwencja). Kontrolery nie potrzebują rozszerzać jakiejś klas bądź implementować specyficznych interfejsów.

Akcje reprezentowane są jako pola do których dopisane jest domknięcie. W URLach dostęp jest przez konwencję, np /sample/action, gdzie sample to nazwa kontrolera (bez słowa Controller) a action to zdefiniowana akcja. W kontrolerze może być zdefiniowanych wiele akcji.

Jeśli nie jest podana żadna akcja, to jest wykonywana akcja domyślna:

• jeśli kontroler posiada jedną akcję, to ona jest domyślna
• jeśli kontroler posiada akcję index to ona jest domyślna
• jeśli posiada właściwość defaultAction, to akcja przypisana do tego pola jest domyślna

Do każdego kontrolera jest wstrzyknięta właściwość log, która jest instancją org.apache.commons.logging.Log

Oprócz log do kontrolera są wstrzyknięte inne pola, jak między innymi HttpServletRequest, HttpServletResponse itd:

• actionName - nazwa wykonywanej akcji
• actionUri - URI do akcji
• controllerName - nazwa kontrolera
• controllerUri - URI kontrolera
• flash - do pracy w zasiegu flash, równoznaczne z params tylko inny zasięg
• log
• params - mapa parametrów
• request - HttpServletRequest
• response - HttpServletResponse
• session - HttpSession
• servletContext - ServletContext

Dostęp do tych obiektów javie (za pomocą servletów)

request.getAttribute("myAttr");
request.setAttribute("myAttr", "myValue");

A w kontrolerach grails

request.myAttr
request.myAttr = "myValue"

Zasięgi (scopes):

• request - obiekty utrzymują się tylko dla bieżącego żądania
• flash - obiekty są dostępne dla obecnego i następnego żądania
• session - są przetrzymywane do momentu aż sesja użytkownika zostanie unieważniona (ręcznie lub automatycznie)
• servletContext - przetrzymywane przez cały czas życia aplikacji. W tym zasięgu obiekty nie są synchronizowane i należy dokonywać synchronizacji ręcznie, np

def index = {
  synchronized(servletContext) {
    def myValue = servletContext.myAttr
    servletContext.myAttr = "changed"
    render myValue
  }
}

Pola z formularzy są przekazywane do kontrolera i dostęp jest poprzez params

def userName = params.userName
log.info("User Name: ${userName}")

Poprzez metodę render można renderować tekst. Można dodać contentType:

render text:'<album>Revolver</album>', contentType:'text/xml'

Najczęściej używa się metody render do renderowia widoków i szablonów GSP.

Przekierowanie ządań odbywa się poprzez metodę redirect:

def first = {
  redirect(action: "second")
}

Metoda ta składa się z mapy, gdzie mogą występować różne klucze:

• action - nazwa akcji do której następuje przekierowania
• controller - nazwa kontrolera do którego następuje przekierowanie
• id - id parametru do przekazania
• params - mapa parametrów
• uri
• url

Domyślny widok dla kontrolera jest pobierany na podstawie akcji i nazwy kontrolera.
Można tworzyć widoki nie standardowe poprzez metodę render.

class SongController {
  def show = {
    render(view:"display",model:[ song: Song.get(params.id) ])
  }
}

widok znajduje się w grails-app/views/song/display.gsp, i zostaje przekazany model Song.
Widok może się znajdować w innym katalogu

render(view:"/common/song", model:[song: Song.get(params.id) ])

wskazuje na grails-app/views/common/song.gsp.
Renderowanie szablonów jest podobne

render(template:"/common/song", model:[song: Song.get(params.id) ] )

przez konwencję nazwy szablonów rozpoczynają się podkreśleniem(_). Szablon to mały wycinek kodu, który widoki mogą dołączać.

W konstruktorze można przekazać mapę parametrów, aby nie robić przypisania każdego parametru oddzielnie:

def album = new Album(params)

Dla istniejących obiektów można w zbliżony sposób przekazać parametry:

def album = Album.get(params.id)
album.properties = params

Walidacja przychodzących danych jest dwustopniowa. Najpierw jest sprawdzana zgodność typów. Jeśli pojawi się błąd obiektu nie można zapisać (read-only). Jeśli to przejdzie sprawdzane są walidatory.
Mechanizm walidacji opiera się na springowym pakiecie org. springframework.validation.

Z punktu widzenia kontrolera jeśli obiekt domenowy jest w nieprawidłowym stanie, należy w logice obsłużyć ten stan, np:

if(album.save()) {
  redirect(action: "show", id:album.id)
}
else {
  render(view: "edit", model:[album:album])
}

Można iterować po błędach obiektu:

object.errors.allErrors.each { println it.code }

Sprawdzić czy istnieją jakieś błędy:

object.hasErrors()

Rendedrowanie błędów w widoku to:

<g:renderErrors bean="${object}" />

Nazwy parametrów, przekazanych w params, są pobierane na podstawie atrybutu name w html, np

<input type="text" name="title" />

Jeśli, należy przekazać parametry do więcej niż jednego obiektu to należy w name dodać jakiś klucz (przestrzeń nazw).

<input type="text" name="album.title" />
<input type="text" name="artist.name" />

I pobranie odpowiednich parametrów to:

def album = new Album( params["album"] )
def artist = new Artist( params["artist"] )

Można zawężać przekazane parametry przy wykorzystaniu metody blindData:

bindData(album, params, [include:"title"])

Można tak zawężać do wielu obiektów, gdzie ostatnim argumentem jest klucz:

bindData(album, params, [include:"title"], "album")

CommandObject, jest to klasa, która ma właściwości klasy domenowej ale nie jest trwała (persistent).
Obiekty żądania definiuje się w katalogu contollers lub w tym samym pliku co kontroler.

Można ograniczyć wywołanie metody Http.POST(Http.GET itd) do konkretnych akcji:

class SomeController {
// action1 may be invoked via a POST
// action2 has no restrictions
// action3 may be invoked via a POST or DELETE
def allowedMethods = [action1:'POST', action3:['POST', 'DELETE']]
def action1 = { ... }
def action2 = { ... }
def action3 = { ... }
}

Jeśli metoda zostanie wywołana w niedozwolonym trybie zostanie rzucony błąd 405 – “method not allowed”

Formatka załączania plików:

<g:uploadForm action="upload">
<input type="file" name="myFile" />
<input type="submit" value="Upload! " />
</g:uploadForm>

obsługa tego:

def upload = {
  def file = request.getFile('myFile')
  // do something with the file
}

Grails automatycznie potrafi rozpoznać byte[] i odpowiednio połączyć z odpowiednią zmienną.

grails-app/views/layouts/main.gsp jest dostępne na każdej stronie.

Klasy domenowe w grails

Kolejny rozdział książki Definitive guide to grails dotyczy klas domenowych. A właściwie to przez większość rozdziału są opisane zachowanie ormowe a właściwe GORMowe. Jak ktoś miał styczność z hibernate to wszystko powinno być proste.

Klasy domenowe zawierają w sobie domyślnie pola id i version.
Ograniczenia dla pól definiuje się poprzez statyczny constraints, którego wartością jest domknięcie

static constraints = { }

zdefiniowane ograniczenia można znaleźć tutaj.

Podczas metody save(), dokonywana jest walidacja i jeśli ona nie przejdzie to jest zwracany odpowiedni komunikat. Klasy domenowe mają pole errors, które jest instancją org.springframework.validation.Errors

Wszystkie klasy domenowe posiadają metodę clearError(), która czyści komunikaty błędów pozostałe po wcześniejszej walidacji oraz validate(), dzięki której można dokonać walidacji “ręcznie”.
Można tworzyć własne walidatory np:

class User {
  static constraints = {
    password(unique:true, length:5..15, validator:{val, obj ->
      if(val?.equalsIgnoreCase(obj.firstName)) {
         return false
      }
    })
  }
}

gdzie obok standardowej walidacji jest walidacja użytkownika. W domknięciu jest sprawdzane czy wartość jest różna od innej wartości tego obiektu. Zamiast wartości można zwrócić błąd.
Ogólny schemat walidacji niestandardowej to:

static constraints = {
  field (validator: {closure})
}

Domyślnie wszystkie właściwości klasy są trwałe (persistant) i są zapisywane do bazy danych. Grails pozwala tworzyć właściwości przejściowe(transient), które nie są zapisywane do bazy poprzez static transients.

class Company {
String name
Integer numberOfEmployees
BigDecimal salary
static transients = ['salary']
}

Pole salary nie jest zapisywane w bazie (brak takiej kolumny).

Jeśli w klasie nie ma pola a jest metoda getPole, to grails traktuje to jakby było dane pole i jest ono persistant. W taki sam sposób można zrobić je transient jak pole.

Można mapować pola do bazy danych. Domyślnie nazwa kolumny jest “taka” sama(mogą być różnice podkreślenia, duże/małe litery). Można utworzyć własne mapowania przez

static mapping = {closure}

np

class Person {
 String firstName
 String lastName
 Integer age
 static mapping = {
   id column:'person_id'
   firstName column:'person_first_name'
   lastName column:'person_last_name'
   age column:'person_age'
   version false
 }
}

W danej tabeli nie będzie pola version. Domyślnie nazwa tabeli jest taka jak nazwa klasy i też można ją zmienić.

static mapping = {
table 'tableName
}

Relacje:
jeden-do-jednego dwukierunkowa(bez właściciela)

class Car {
Engine engine
}
class Engine {
Car car
}

jeden-do-jeden dwukierunkowa (z właścicielem). Klucz mapy jest jako właściwość.

class Car {
Engine engine
}
class Engine {
static belongsTo = [car:Car]
}

jeden-do-jeden jednokierunkowa

class Engine {
static belongsTo = Car
}

belongsTo zapewnia usuwanie kaskadowe(cascade delete). Jeśli zostanie usunięty Car to jednocześnie zostanie usunięty Engine.
jeden-do-wielu

class Artist {
String name
static hasMany = [albums:Album]
}
class Album {
String title
static belongsTo = [artist:Artist]
}

Relacje jeden-do-wielu mogą być jednokierunkowe jak i dwukierunkowe. Dla jednokierunkowych podaje się tylko klasę do której obiekt należy, przy dwukierunkowej tworzy się mapę.
hasMany musi być mapą, gdzie klucz jest właściwością dla danej klasy (java.util.Set). Jeśli potrzeba innego typu to należy go zadeklarować jawnie (Czasem będzie wymagana implementacja interfejsu Comparable – dla danych list).

class Album {
  static hasMany = [songs:Song]

  SortedSet songs
}

Jedna klasa może być w wielu relacjach jeden-do-wielu:

static hasMany = [albums:Album, instruments:Instrument]

Dziedziczenie
Są dwie możliwości mapowania klasy i jej podklas w tabeli.
Pierwsza i domyślna jedna tabela dla wszystkich klas (table per hierarchy). Tabela zawiera wszystkie pola z klasy głównej i podklas, dodatkowo pole class które określa jaka to klasa (krytyczne dla grails).
Druga osobna tabela dla każdej klasy (table per subclass). W klasie nadrzędnej należy ustawić:

static mapping = {
  tablePerHierarchy false
}

Można umieszczać 2 klasy w jednej tabeli (embeddeding object), użyteczne przy relacjach jeden-do-jeden, gdzie obiekty są w różnych tabelach i mają oddzielne id. Zagnieżdżenie powoduje, że wartości są w jednej tabeli.

class Car {
  String make
  String model
  Engine engine
  static embedded = ['engine']
}

W grails są testy jednostkowe i integracyjne.
W testach integracyjnych można testować metody dynamiczne, większy wycinek systemu, trwają one dłużej (między innymi kosz utworzenia środowiska). Testy jednostkowe są krótsze i testują konkretne zachowania “statyczne”, jako drobny wycinek. Przy tworzeniu klasy domenowej automatycznie jest tworzona klasa testu jednostkowego dla danej klasy.
Poleceniem test-app zostaną uruchomione wszystkie testy jednostkowe i integracyjne. Jeśli po tym poleceniu zostanie podana nazwa klasy (bez słowa test np tak jak nazwa klasy domenowej) to zostaną wykonane testy dla tej klasy. Podstawową klasą testową jest grails.test.GrailsUnitTestCase