Grails-1.1を斬る！~Grails-1.1からのチーム開発~ in Tokyo

JGGUG 第弐回 g* workshop

Grails-1.1を斬る！
∼Grails-1.1からのチーム開発∼

間近
リース
.1. 1リ
r ai ls-1
G

def speaker = new Cast(name:”T.Yamamoto”,version:”G*2-2009-05-08”)

自己紹介
名前：山本剛 (やまもとつよし)
所属：ニューキャスト

「Grails徹底入門」9-11章、書きました。
Grails Acegi Plugin作った人。

ブログ
http://xmldo.blogspot.com/
http://d.hatena.ne.jp/mottsnite/

こっちがメインかも

Grailsとは？
よく聞く説明
「Groovyで実装されたRuby on Rails」!?
合ってるようで間違い
Java＋Groovyで実装された、CoC、DRYの概念を取り入
れた( RoR にインスパイアされた)、Webアプリケーション開発環境。
基礎はJavaでの開発で信頼されたSpring,Hibernate等を
使用している。
そして、それらをシンプルに利用できる環境。

Grails, the Platform (DGG2引用)

Grailsの構成図
Grails Groovy
Spring Hibernate SiteMesh
基礎部分はJava(+Groovy)
JVM

Hibernate:ORマッピング
Spring: DIコンテナ・多機能なラッパーフレームワーク
SiteMesh:レイアウトフレームワーク

Jetty: サーブレットコンテナ
HSQLDB:ピュアJavaなデータベース

デモ
grails create-app demo
cd demo
grails create-domain-class Book
grails create-controller Book
grails run-app
ブラウザで開く
--止める--

grails install-plugin acegi
--プラグインインストールは前より早くなった!!
※要ネットワーク

Grails-1.1リリース
Java5以上での動作
CIとかに!
Ant+IvyとMavenビルドのサポート
スタンドアロンGORM Springな人へ!
プラグインの新機能：グローバルプラグイン、他動推移的なプラ
グイン解決、ローカルリポジトリー対応、他
チーム!?
Springネームスペースサポート
劇的に向上したパフォーマンス
マジ!?
テストフレームワーク
MVCレイヤーとGORM等のGrailsコアへの多くの新機能と改善

Groovyは最新の1.6に更新

Grailsの構成図
Grails
.1 4 Groovy
Spring 3.
Hibernate 3
SiteMesh 2.
6 5
5. 1.
2.
基礎部分はJava(+Groovy)
JVM 5
1.

Hibernate:ORマッピング
Spring: DIコンテナ・多機能なラッパーフレームワーク
SiteMesh:レイアウトフレームワーク

. 14
Jetty: サーブレットコンテナ 6.
1
5
HSQLDB:ピュアJavaなデータベース . 0.
1.8

各APIのバージョン
1.0.5 → 現在

hibernate-3.2.6.ga → hibernate-3.3.1
jetty-6.1.12 → jetty-6.1.14
spring-2.5.6 → spring-2.5.6
sitemesh-2.3 → sitemesh-2.4
hsqldb-1.8.0.5 → hsqldb-1.8.0.5
groovy-all-1.5.6 → groovy-all-1.6.3-SNAPSHOT

長くなるので、

一気に紹介。

GORM
スタンドアロンでGORMが使用可能！
Spring MVCでのサンプル、GRAILS_HOME/samples/petclinic-mvcを参照 ty
E nti
applicationContext.xmlにデータソースと、<gorm:sessionFactory/>の定義 nce.
si ste
<gorm:sessionFactory base-package="org.grails.samples" . per
data-source-ref="dataSource" ils
tgra y
message-source-ref="messageSource">
im por y { gr oov
it on .
<property name="hibernateProperties"> t rs
@En s Pe name son
<util:map> s Per
cla tring
<entry key="hibernate.hbm2ddl.auto" S
value="update"/> ...
</util:map> }
</property>
</gorm:sessionFactory>

GORMイベント - イベントbeforeInsert,beforeUpdate,beforeDeleteに、さらにafterInsert,
afterUpdate , afterDeleteが追加された。 :String]
any = [name
他に、基本型(String,Integer)、 Enum でのコレクション。 static hasM
.read( 1)
読み取りのみのオブジェクト取得。ソートのデフォルト値の設定。 def b ook = Book
バッチフェッチ。 static m
apping =
static mapping = { sort "na {
ダイナミックファインダの向上。 batchSize 15 me"
books so
rt:"titl
joinTable！ } } e"
generatorの指定
static mapping = {
id generator:"org.hibernate.id.enhanced.SequenceStyleGenerator",
params:[sequence_name:'item_id_seq',initial_value:1000,increment_size:1]
}

GSP(Groovy Server Pages)
GSPでのJSPタグライブラリのサポート
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>

JSPタグを使う！
<fmt:formatNumber value="${10}" pattern=".00"/>

メソッドのように使う！
${fmt.formatNumber(value:10, pattern:".00")}

_tableRow.gspの中身
テンプレートネームスペース
<tr>
<td class="prop">${label}</td>
<td class="value">${value}</td>
</tr>
ネームスペースtmpl+ _ を無くしたファイル名で呼び出す。
<tmpl:tableRow label="one" value="two" />

Server Side Includes - <g:include>タグで別のコントローラ、ア
クションを呼び出せる。 <g:include controller="book" action="list"/>

コントローラあるいはタグライブラリでは、メソッドとして呼出も可能！
def content = include(controller:"book", action:"list")

パフォーマンスの改善

データバインディング
サブセットプロパティ
今までは、以下の方法で全プロパティがバインドされました。
person.properties = params
サブセットプロパティの対応で、指定した項目のみバインドも！
person.properties["firstName","lastName"] = params
同じ方法でアクセスも可能！
person.properties["firstName","lastName"].each { println it }

コレクション型への対応
<g:textField name="books[0].title" value="the Stand" />
<g:textField name="books[1].title" value="the Shining" />
<g:textField name="books[2].title" value="Red Madder" />
自動的に収集してまとめてくれます。

コントローラ関連
RESTfulマッピングの指定方法の向上
"/books"(resource:"book") の指定で、
GET, PUT, POST, DELETEを自動的に、
アクション"show", "save", "update", "delete"に設定
多重サブミット対策
フォームに、<g:form useToken="true">を指定すると、コントローラ
内で、withFormを使用してフォームの多重サブミットを判別できるよ
うになった。 withForm {
// 正常なリクエスト
}.invalidToken {
// ダブルクリックしたな？
リクエストのフォワード }

forward controller:"home", action:"index"

エラーハンドルの宣言
UrlMappingsにエラーハンドルの宣言が可能に。
"500"(controller:"errors", exception:IllegalArgumentException)

Scaffolding
ダイナミックスカッフォルディングとテンプレート
ダイナミックスカッフォルディング時のテンプレート
は、grails install-templates コマンドでインストールされ
たテンプレートを使用するようになった。
ダイナミックなのに微調整できる！
スカッフォルドでのM-to-M対応！

その他
Maven統合
Ant + Ivy統合 - Grailsが生成するAntのbuild.xmlとivy.xmlで、Grails
がインストールされていない環境(CIサーバ等)でもビルド可能。
Log4j DSL
Environment(環境) 、Metadata(メタ情報) API MENT EL OP
nme nt.DEV
nv iro rrent
ls. util.E tad ata.cu
grai .u til.Me e
ta = grails ationNam
c
de f metada data.appli
eta
pri ntln m

非インタラクティブモード
BeanBuilderでSpringネームスペースに対応
テストフレームワーク - Testingプラグインは、本体に統合！
Encrypted Data Sources - データソースパスワードの暗号化

まだまだ有ります。
ここからは、
チーム開発に便利!?な・・

BuildConﬁg.groovy
プロジェクトのビルドに関連する情報をカスタマイズでき
る定義ファイル
Grails-1.0.x系では、Grailsのコンパイルされたクラスなどは、
$USER_HOME/.grails/<バージョン>/以下に固定されていましたが、
Grails-1.1からは指定変更可能になりました。
ファイルの設置場所
$PROJECT_HOME/grails-app/conf/BuildConﬁg.groovy
中はこんな感じ↓

grails.project.plugins.dir="work_tmp/plugins"
grails.project.work.dir="work_tmp/work"
grails.plugin.location."feeds"="./plugins/feeds-1.4"

BuildConﬁg定義できる内容
※主な項目のみ
grails.project.work.dir
プロジェクトの作業ディレクトリ
(このディレクトリ以下に classes,resources,plugins等が配置される)
デフォルト：$USER_HOME/.grails/<バージョン>/projects/<プロジェクト名>/
作業ディレクトリ以下を個別に指定も可能
grails.project.plugins.dir
プラグインのディレクトリ。
grails-1.0.xでの、$PROJECT_HOME/plugins
デフォルト：$USER_HOME/.grails/<バージョン>/projects/<プロジェクト名>/plugins
grails.project.test.reports.dir
テストリポート書きだし先。
grails.project.class.dir
クラスの書きだし先。

何でBuildConﬁgで設定変える必要があるの？
個人的な意見・・・。
grails.project.class.dirのように、コンパイルクラスを置く場所はよいとして、Grails-1.1
からプラグインの場所が変わってしまったので、Grails-1.0.xを使っていたユーザには、プ
ラグインのディレクトリが近くにいないのは・・・・。
で、 grails.project.plugins.dirで場所を変更すると、プラグインの場所が近くで管理でき
るのでわかりやすい。
ビルドサーバなどでの事情もあるし！

変な所にファイル置かれても・・

じゃあ、変えられればOKでしょ！

管理できるのは良いこと！

プラグイン個別のパス指定
プラグインを個別に指定することもできます。
grails.plugin.location."ext"="./plugins/ext-0.1"
grails.plugin.location."form-maker"="./plugins/form-maker-0.1"
grails.plugin.location."rhino"="./plugins/rhino-0.1.1"
grails.plugin.location."waku-script"="./plugins/waku-script-0.2-SNAPSHOT"
grails.plugin.location."yui"="./plugins/yui-2.6.0"
grails.plugin.location."resources"="./plugins/resources-0.1"
grails.plugin.location."taggin"="/works/experiment/grails-taggin/trunk"

プラグイン開発に便利！ーが！
ンバいね
ムメて良
チーなく
間違え

どの辺がチーム開発？

で、ここで強引に

プラグインの話！

Grailsプラグインとは？
自分のプロジェクトに便利な拡張機能を追加できる
公式プラグインも有ります！ユーザ認証機能とか、メールとか、
コマンド install-pluginで簡単に追加できる
そもそもGrails自身がプラグインの集合体！
通常のGrailsプロジェクトと構造が同じ！
∼GrailsPlugin.groovyファイルの有無

詳しくは！

ん？
各機能をプラグイン分けすると、開発を分担できそうだ！

プラグインA
インストール (プロジェクトの一部の機能)

プラグインB
メインプロジェクト
グラフ機能プラグイン
インストール
(今後も再利用できそうな機能)

ユーザ認証プラグイン
インストール
(公式のプラグイン＋カスタマイズ)

この辺がチーム開発！＋再利用性！

前から有るのに、何故いまさら主張するの？
Grails-1.0.xでの問題点
他のメンバーがさわってしまったりして・・・
すぐさわれるので、ついカスタマイズ・・・
プラグインの派生が・・・

EMERGENCY EMERGENCY EMERGENCY EMERGENCY EMERGENCY EMERGENCY

中身が変わってるかもね！
ENCY EMERGENCY

EMERGENCY
EMERGENCY

EMERGENCY
EMERGENCY

EMERGENCY
EMERGENCY

EMERGENCY
EMERGENCY

EMERGENCY
EM

EMERGENCY

ENCY EMERGENCY EMERGENCY EMERGENCY EMERGENCY EMERGENCY EM







管理しにくい!

EMERGENCY EM
ENCY EMERGENCY EMERGENCY EMERGENCY EMERGENCY



EMERGENCY
オリジナルかわからないね！
EMERGENCY EMERGENCY EMERGENCY EMERGENCY EMERGENCY

Grails-1.1からの、プラグインの新機能
グローバルプラグイン
複数のプラグインリポジトリ
他動的なプラグイン自動解決
(Automatic Transitive Plugin Resolution)
プラグインでのモジュール式アプリケーション開発
プラグインスコープと環境定義

グローバルプラグイン
"-global"オプションを指定することによって、プラグイン
はグローバルプラグインとして管理されます。
インストールされたプラグインは、同じ場所に保管されて、
一度インストールすれば、同じバージョンのGrailsで他のア
プリケーション開発するときは再度インストールすること
なく使用することができます。

grails install-plugin acegi -global

グローバルは、
必ず毎回とりこまれる!?
有る意味便利だけど...

・・・物によっては不便!? orz

そんなあなたにこんな新機能！

Grails-1.1からプラグインは基本的に
application.propertiesにメタ情報で管理されます。
app.version=0.1
plugins.acegi=0.5.1
app.servlet.version=2.4
ン
app.grails.version=1.1-SNAPSHOT
名= バージョ
plugins.hibernate=1.1-beta3 s.プラグイン
app.name=relationsample plugin

プラグインの追加削除、バージョン変更は、
プロジェクトのapplication.propertiesの内容を変更する
だけでよいのです。
これで、他のチームメンバーへのプラグイン変更通知も
楽々。リポジトリに投げれば

他動的なプラグイン自動解決（※仮翻訳）

application.propertiesの情報を元に、
プラグインリポジトリから、
自動的にバージョン確認して、
インストール、アンインストールを行ってくれます。

但し、run-appを2回！
ーが！
ンバいね
ムメて良
間違った操作を防げます！チーなく
間違え

¿E
ld
¿これって、

ep
ó
sit
公式プラグインリポジトリの

os
プラグインにしか

ólo
対応していないんぢゃん?¿!

oﬁ
c
ial
?

Grails-1.1から独自のプラグインリポジトリを設定するこ
とができるようになりました。
設定方法
USER_HOME/.grails/settings.groovy 又は、
grails-app/conf/BuildConﬁg.groovyに情報定義。
例えば、チームのプラグインリポジトリに使用するSVN
のUrlが、"http://127.0.0.1/gp"だとしたら
grails.plugin.repos.discovery.local="http://127.0.0.1/gp"
grails.plugin.repos.distribution.local="http://127.0.0.1/gp"

grails.plugin.repos.discovery.リポジトリ名称="リポジトリへのHttpベースのURL"
grails.plugin.repos.distribution.リポジトリ名称="リポジトリへのHttpベースのURL"

独自のプラグインリポジトリ設定をすることによって、プラ
グイン関連のコマンドlist-plugins,install-pluginで設定し
たプラグインリポジトリも同時に参照してくれます。
個別に参照する場合は、以下のように設定したリポジトリ
名称を指定します。
grails list-plugins -repository=リポジトリ名称

独自のプラグインリポジトリに
プラグインをリリース
プラグインプロジェクトディレクトリでrelease-pluginに
-repository=対象リポジトリ名称を指定して実行。
grails release-plugin -repository=リポジトリ名称

以下の内容を行ってくれます。
1. プラグインのパッケージング
2. プラグインリポジトリへのプラグインの追加
(grails-プラグイン名の階層に、tags trunkを追加)
3. プラグインのバージョンを自動でタグ切り
4. プラグインリポジトリにある、プラグイン管理の
.plugin-meta/plugins-list.xmlを更新

チーム用の
プラグインリポジトリ！

Grails-1.1は

いろいろ、便利。

元々

プラグインA

プラグインB
グラフ機能プラグイン
インストール

インストール

プラグイン
これから！
チーム用プラグインリポジトリ
Grails公式プラグイン

チーム用リポジトリ
プラグイン

プラグイン自動解決
メタ情報で自動管理独自プラグインリポジトリで管理

プラグインB
(プロジェクトの一部の機能)
使用する
プラグインの情報を
プラグインA
定義
(プロジェクトの一部の機能)

チェックアウトグラフ機能プラグイン

チームメンバー

プラグイン自動解決

まとめ
application.propertiesにプラグイン情報を保持するため、
チームメンバー間でのプラグインバージョン管理が楽に！
BuildConﬁg.groovyで、開発時のビルド場所や、
プラグイン情報をまとめやすくなった。
見えないゴミ減る！
プラグイン開発時のソース分けが以前より楽に！

開発プロジェクト内容の切り分けをプラグイン別にし、
チーム用プラグインリポジトリを活用することで、開発した
内容をプラグインとしての再利用が期待できる！

Grails 1.1.1
GAE/Jの対応試したから、ブログみてね！

Grails-1.1のバグフィックス＆機能向上

250件くらい！
Groovy 1.6.3

ぉぉ！

次回

まだ未定ですが…
ビ
ー
ン
ビルダー!?

Grails-1.1を斬る！~Grails-1.1からのチーム開発~ in Tokyo

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à Grails-1.1を斬る！~Grails-1.1からのチーム開発~ in Tokyo

Similaire à Grails-1.1を斬る！~Grails-1.1からのチーム開発~ in Tokyo (20)

Plus de Tsuyoshi Yamamoto

Plus de Tsuyoshi Yamamoto (20)

Dernier

Dernier (7)

Grails-1.1を斬る！~Grails-1.1からのチーム開発~ in Tokyo