今号は 36 ページ $5. ご注文はこちらから.
素の PDF にコード例が付いてきます.
(groovy と grails 開発者のための) Groovy Magazine が創刊されました.
http://www.groovymag.com/有料 ($5.00) のオンライン・マガジンです. 英語ですけど. 登録したメイル・アドレスがテキストとして各ページの片隅に埋め込まれます. 記事中のサンプル・コードなどはテキスト・ファイルとして同梱されています.
創刊 11 月号 (31ページ) の目次はこんなんです.
Groovy は関数型言語のようにリストを扱えるようにはなっている. しかし惜しい...
例えば, [1,2,3] と [4,5,6] という二つのリストをマージして, [[1,4] ,[2,5] ,[3,6]] というようなリストを作りたいとする (変態なマージだけど).
普通に考えるとこんな感じになる.
def merge = { x, y, r = [] -> x == [] ? r : merge(x-x[0], y-y[0], r+[[x[0] , y[0]]]) }まぁ記法がいいかどうかは別として, 意味は分かると思う. ところが Groovy1.5 でこれは動かないのだ. merge の定義中に再帰的に現れる merge を理解できないのだ. そこで次のようにすれば動く.
def merge; merge = { x, y, r = [] -> x == [] ? r : merge(x-x[0], y-y[0], r+[[x[0], y[0]]]) }馬鹿でしょ. ま, いいけど.
メモ代わりに残しておく.
Grails ではプラグインは強力な仕組みだけど, テストが難しい (場合がある). 特にアーティファクトのダイナミック・プロパティに依存するようなものはテストしにくい.
ここではごく簡単に, Controller に定義された特定のプロパティの値で振る舞いを変えるようなプラグインを考えてみる.
このようなプラグインをテストする最も簡単な方法は, テスト用のコントローラを定義して, ./grails-app/controllers/ の下に置き, integration test を実行することだ. でも, この方法だとテスト用のコントローラがプラグインのインストールを通してアプリケーションに入り込んでしまう. package-plugin 時に注意深くテスト用のコントローラを取り除くという手もなくはないけど, これは避けたい.
またテスト本来の目的からするとテスト用のコントローラがテストの外にファイルの形で存在するのは本当は嬉しくない. じゃあ, テストの中に定義してしまえということになる.
def gcl = new groovy.lang.GroovyClassLoader()
void setUp() {
gcl.parseClass(
'''
class TestController {
def action1 = { render "action1 called" }
}
'''
)
}このようにすると, テスト用のコントローラの定義もテスト・コード中に入れることが出来る. が, 残念なことにこのままでは TestController はコントローラ・アーティファクトとして認識されないので, 例えば render などというダイナミック・プロパティは注入されない.
そこで次の手は, こうやって書いたコントローラも正しいコントローラ・アーティファクトとして無理矢理認識させる方法だ. 実際, grails 本体のテスト・コードを見ると, このようなテストのための GroovyTestCase として, org.codehaus.groovy.grails.web.servlet.mvc.AbstractGrailsContollerTests がある. ただし, AbstractGrailsControllerTests は Test モジュールに入っているので, 普通の grails アプリケーションやプラグインからはアクセスできない.
じゃあ, このクラスをファイルごと自分のプロジェクトにコピーしてしまえ! (grails-1.0.2/test/groovy/org/codehaus/groovy/grails/web/servlet/mvc/AbstractGrailsControllerTests.groovy) 実はもう一つのクラス, MockGrailsPluginManager も必要になる. これも同じようにコピーしてくる (grails-1.0.2/test/commons/org/codehaus/groovy/grails/plugins/MockGrailsPluginManager.java). 置き場所は例えば test/integration 辺りでよい (パッケージに合わせてディレクトリを掘らなくてもよい). ただし, AbstractGrailsControllerTests の最初の import 文 (import org.codehaus.groovy.grails.commons.test.*) はエラーを起こすのでコメントアウトしておく必要がある.
で, さっきのようなテスト・クラスは
すると, 上記 TestController はちゃんとコントローラ・アーティファクトとして認識されるようになる. つまり, render などが使えるようになる.
でもまだまだ残念なのだ. この Mock 環境では例えば Filter などはちゃんと (つまり run-app するのと同じようには) セットアップされないようなのである. つまり Filter にも何か追加しているようなプラグインのテストはやっぱり出来ない... (これは最初の方法でやっても結局同じ).
結局 webtest でもするしかないのである. この結論を得るためにどれだけ回り道をしたことか.
注:
最初の手法 (テストの外でコントローラを定義する) でもう少しマシなやり方もある. テスト・コントローラを正式な contollers ディレクトリではなく, test/integration/controllers 辺りに置くのである. その代わり, GrailsPlugin 定義の中で, watchedResources と onChange にも手を入れなければならないけど. このままプラグインをパッケージしても, まぁ許されるんじゃないか...?
Grails はある意味では, (巨大で複雑な) springframework (今やlightweightとは言いにくいよなぁ) の wrapper という側面がある. Grails をある程度突っ込んでいくと, springframework に触れざるを得ない. とは言え, springframework をまるごと学習するのは大変だ.
ということで, (本を書く都合もあって:-) Grails が springframework のどの部分を使っているか, Grails を使うに当たって springframework のどの部分が分かっていればいいか, ざっと調べてみた.
例えばspring のリファレンス・マニュアル (2.5.1) でいうと,
3. The IoC Container の特に 3.8 まで
4. Resources の全体
5. Validation , Data-binding, the BeanWrapper, and PropertyEditors の全体
9. Transaction management の 9.4 までと, 9.6
12. Object Relational Mapping (ORM) data access の 12.2, 7
13. Web MVC framework の 13.9, 12, 13 以外
Grails で使われている Spring の機能はざっとこんなところだと思う. 細かく言うと, ユーティリティ的なものとかもあるし, 見落としているのもあるかもしれないし, もしかしたら以下も見ておくといいかもしれないが,
7. Spring AOP API の一部
11. Data access using JDBC の一部
ま, こんなもんだろう. とは言え, 600 ページ近いリファレンスの 1/4 くらいに相当するかな? もちろん普通に使っている分には, これ全部知っている必要はないのだが.
# ここには別パッケージになっている WebFlow や, プラグインになっている Acegi Security, Quartz などに関連する部分は含んでいない
自分で作っているサービスの関係で, taggable plugin, searchable plugin を見たり, 試したりしているんだけど, 面白い.
% grails install-plugin Searchable
して (ネットワークの向こうのリポジトリからダウンロードされる), 適当なドメイン・クラスに
static searchable = true
を挿入するだけで, 裏で検索エンジン Lucene が走って, そのドメイン・クラスの String フィールドなどを対象に次のような検索ができるようになる.
やろうと思えば, どのフィールドを検索対象にするかとか指定できるし, 検索画面はもちろん自分で作り直せばよい.
ただし, static scaffold すると (generate すると) URLMapping に問題があると言って転ける (dynamic な scaffoldならばちゃんと動く). とりあえず../plugins/Searchable-0.4-SNAPSHOT/grails-app/conf/SearchableUrlMappings.groovyから "/searchable "の定義を取り去れば動くようになる. 原因は突き止めてない.
一方, taggable pluginは自分で plugin をダウンロードして, やはり install-plugin する.
すると, implements Taggable したドメイン・クラスに, addTag("foo") とかできるようになる. このタグとは blog なんかで使われる意味のタグですね. タグからドメイン・オブジェクトを検索するメソッドは (まだ?) ないとか, どうも gsp から (今のところ) うまくアクセスできてないなどという欠点はあるものの, 面白いでしょ?
gsp から他のフィールドと同じように tags を扱えないのは, Controller の setProperties()/getProperties が inject されたフィールドに対して動作しないからのようだ. plugin でこれらを上書きするか, 明示的に set/get すればよい.
この二つの例の何が面白いかというと, 複数のオブジェクトを横断するいわゆるアスペクトを, grails ではプラグインとして実装すればよいということなのだ. だって「タグ付け (分類) 可能なオブジェクト」は継承とは関係なくいろいろあるだろうし, タグ付け可能かどうかはドメインの本質とは関係ないから分離したいわけだ. プラグインなら後から簡単に付けたり外したりできる. 「検索可能なオブジェクト」というのも同じ.
# この二つの例に限らず, grails 自身がいわばアスペクトの固まりなのですが.
実は「ビジネスパターンによるモデル駆動設計」は, ビジネス系アプリケーションの構造をリソース, イベント, エージェントの組み合わせで, 振る舞いを識別, 期日, 説明, 注釈, 場所, 分類, 通知, 価値のようなアスペクトのパタンで組み上げてしまおうというなかなか頭のよいアイデアなんだけど, この振る舞いのパタン (アスペクト) をまさに grails だとプラグインで実装すればいいわけだ.
# 元の本は惜しいことに .NET を使っている.
エンタプライズ 2.0 系のアプリケーションには, grails はよく効きそうだ.
grails-1.0 がリリースされましたが, まだ細かい (!?) 問題は起きているようです.
そのひとつ.
% grails generate-allなどをすると, "you tried to assign a value to the class 'resources'." などと言われて転けます.
これは <grails>/scripts/GenerateAll.groovy の 53 行目の 'resources' を 'this.resources' にすると吉.
これも問題は既に JIRA にファイリングされているので, grails-1.0.1 では治ると思います.
1.0 も相当よくなってはいますが, grails-1.0.? がいくつか出て, 本物になるのでしょう.
日本だと「達人プログラマ」のシリーズで出ている, Pragmatic Programmes から Groovy 本が二冊出ました. というか, 正式には 3 月 15 日に出るのですが, PDF のベータ版がリリースされています.
一冊は Groovy Recipes, もう一冊は Programming Groovy.
Recipes の方は, 名前の通り濃いめの内容になっていて, grails (1.0) の話題も 2 章分含まれています. 著者は aboutGroovy.com をやっている人なので, まぁコミュニティの中の人と言っていいかな. Programming の方は, Java プログラマ向けの入門書. 著者はコミュニティの中の人ではなく, もっと一般的なライタ. どちらも groovy は 1.5 ベースのようです.
PD F版は $22, PDF と紙の本 (正式に発刊されたら送ってくれる) のセットは $44, 紙の本だけだと $35. でも送料が一冊だと $13, 二冊だと $39! (なぜか 3 倍).
しかし, 未完の原稿をどんどん PDF にして売ってしまうって面白いすね. しかも PDF 版の各ページのフッタには, "Report Erratum" という http リンクが埋め込まれていて, サイトに飛ぶと「このページのどういう間違いを誰が申告したか」レポートできる. 金払った読者をレビュア扱いだ. クヌスみたいに, レポートの数によって割り引いてくれるといいんだけどなぁ. 一部省略されているコード例にはやっぱりリンクが付いていて, 本物のコードをダウンロードできたりもします.
日本の出版社も頑張らないと.
達人プログラマの邦訳はだいたいオーム社から出てるようですが, この二冊も出すのかな?
