まえがき
なんこれ？
なんの因果かJavaもスクリプト言語も好きじゃないぼくが Groovy/Grails という新しい環境でお仕事を始めたので、色々と新しい事を勉強中。
調べたこととか、学んだこととか、解らんこととか、意味不明なこととか、理解不能なこととか、お手上げなこととかをつらつら書き残しておこうと思います。
どんな？
ちなみに現状を簡単に述べると、解らんことがあっても、Groovyで調べればいいのか、Grailsで調べればいいのか、それすらも良く解らんちゃん。
（とりあえず両方でぐぐってどっちが正解か当てるゲーム）
要はアレですよ、チラシの裏ですよ。
どういう？
こうした未整理の技術情報っぽいものは、「雑記」タグだと流石にアレなんで、「仕事」カテゴリの一種として「開発日誌」タグを付けていこうと思います。
ぐるーびー。
取り敢えず、いくつかの機能改修をやる事になった（と言うか、簡単なものは既に終えた）ので、それを通してまず Groovy/Grails の世界に触れていこうと思う。
じーえすぴー。
grails-app/views ってところに大量に .gspファイル が突っ込まれてて、どうやらコレが Grails:View というものらしい。
要するにアレね、JSPのGroovy版ね？
第一印象、あんま好きじゃない：
JSPはね、初めてJava/Webの開発に来た時に半年くらいだけちょこっと触ってたけど、正直あんま好きくない。
何か、ビューと言う割にはロジカルな要素が入り込み易いし、字面的にもゴチャゴチャして合わなかった。
それより個人的にはJavaEE開発で触ったJSF（primefaces）の方が好みに合ってた。
.NET 出身で ASP.NET を多少齧ってたから、何となくサーバ側でコンポーネント管理するっていう基本思想が合ってたんだと思う。
現場のプロジェクトを眺めてて思った事：
ところで script タグにjavascriptガリガリ書かれてるのが死ぬほど気持ち悪いんだけど、
何か .jsファイル が使えない理由があるのかなぁ？？？
assets/javascripts の中にはjsライブラリ系（jQueryとか）の ,jsファイル が突っ込まれてるだけだった。
ここの開発のローカルルールなのかしら？
こんとろーら。
で、見た感じViewと一対一で紐付いている "gsp名" + "Controller" .groovy ってのが Grails:Controller というモノらしい。
こいつらは grails-app/controllers に突っ込まれてた。
JSFに於けるManagedBeanみたいなもんですかね。
現場のプロジェクトを眺めてて思った事：
いわゆるプレゼンテーションレイヤの処理をここでやるっぽいですが、 ここのプロジェクトでは論理レイヤをあまりキッチリ分けてはいないらしく、 コントローラに色々とビジネスロジックやら何やらがモロ乗りしてるみたい。
(*'▽') うーん、ぐちゃぐちゃ。
ところでManagedBeanの時はバインドするbean名をアノテーションで指定出来たけど、 GSPではコントローラとビューの紐付はどういう仕組みになってるんだろう。
気になるので、ぼちぼち調べていきましょうね。
どめいん。
grails-app/domain 配下に突っ込まれてる、テーブル名と同じgroovyクラスどもが Grails:Domain と言うものらしい。
見た感じ、JPA（JavaEEのORMapper）のEntityManagerに対するEntityみたいなものか。
ざっと見てみた感じ、これは凄く良さそうなものです、テンションが上がって来ました！！
validation
プロパティごとに validator: アノテーションもどきで匿名メソッド（？）*1を実装できて、こいつがいわゆるカスタムバリデータとして動作するようだ。
バリデーションは domain.validate() で呼び出すと動くっぽい。
パッと見は単なるPOJOで、制約的な記述をしてあるだけで、物凄くシンプルですね。
これは良き良き。
transient
どうやら static transients = { "プロパティ名" } とメタ情報を仕込んでおくことで、
プロパティごとに、何て言うの、JPAのEntityで @Transient アノテーションを付けたのと同じく、永続化対象外に出来るみたい。
（あるいは @JsonIgnore や [XmlIgnore] みたいなものね）
個人的には文字列指定でこう書くなら、素直にアノテーション付けた方が良いなーって思うけど。
static
他にも static キーワード使ってメタ情報を仕込めるのが色々とあるらしい。
ちょっと纏めて時間取って調べたい。
save
domain.save(); でドメイン（に対する変更）が保存されるらしい。
JPAで em.merge( Entity ); するようなもんか。
普段は「エンティティ」って言ってるものが、Groovyの開発では「ドメイン」って言うっぽいね。
デフォルトではこのときに domain.validate(); が実行される仕組みになっているが、
domain.save(validate:false); にすることでオフに出来るらしい。
業務システム開発だとたまにこういう要件もあるが、それにも対応出来ている、素晴らしい。
errors
ほんでもって、domain.validate(); するとバリデーションチェック結果を示す真偽値 true/false が返ってくるっぽい。
肝心のバリデーションエラーの詳細情報はどうするんだと思ったら、それは domain.errors プロパティにぶっこまれるくさい。
わからんこと。
で、このクラスがドメインクラスである事を示すマーカ的なものはないのかしら？
JPAだとEntityに対しては @Entityアノテーション をつけたりしてたんだけど、、、。
@Domain とかアノテーションが張ってある訳でもなければ、extends GroovyDomain みたいに基底クラスを継承している訳でもない。
Groovyのドメインクラスをドメインたらしめている何者かはどこに書いてあるのだろう？？？
まさかとは思うけど、特に何もなくて domain フォルダ配下に突っ込んだクラスは全部そうなるとかってアグレッシブな話じゃないよね？？
どっかに xml とかがあるのかなぁ？
この辺はきちんと調べよう。
おわり
っていうかんじ。
ほんとはこれこないだの土日に書く予定だったんだけど、うっかりしてた。
(*'▽') てへぺろ。
と言う事で、これから Groovy/Grails がんばります。
