Advent Calendarに参加してみたくてブログを始めてみました！よろしくお願いします！
こちらはJava EE Advent Calendar 2013 - Adventar 20日目の記事です。
前日の記事はAOE Takashiさんの「 Java EE Managed Beanについて (Java EE Advent Calendar2013 19日目) - AOEの日記 」でした。
本日はJava EEと併用するテンプレートとして、しばしば話題にあがるThymeleafについて思うところを書きました。
Thymeleafすばらしい
業務ではJSPを利用しているのですが、以前、下記の記事に触発されてからThymeleafを取り入れたいと画策しています。（いまだロビー活動が実っていませんが・・・。）
デザイナーさんたちとの協業を推し進める Thymeleaf | Nulab Tech Blog
テンプレートがHTMLとして扱えてタグの属性部分に変数を記述するスタイルのため
- APサーバを立てなくても直接ブラウザでテンプレートのレイアウト確認ができる
- テンプレートにダミーの文言を書き込んでおけば画面モックとしても利用できる
- ダミーの文言はAPサーバ上でバインディングする際に置き換えられる
という特徴があります。以下は公式ドキュメントに紹介されている図ですが
Thymeleafのテンプレートをそのままブラウザで確認した図
一方JSPファイルをそのままブラウザで確認した図
Thymeleafすばらしいですね！
以前、JSFがHTML5フレンドリーになったという記事を拝見して、JSFにも興味津々なのですが、ブラウザでファイル確認した際、#{caption}のようにバインド前の変数が表示されてしまう点は回避できなさそうです。（ざっくりとしか調査していないので、もしかしたらうまい方法があるのかもしれません・・・。）レイアウトを見るときに文言の量も結構重要な要素なので、それっぽい文言をいれた上で画面確認をしてみたかったりします。
<h3 th:text="${caption}">テンプレートについて</h3>
Thymeleafでは上記のようにタグを記述すると静的にファイルを確認する分には「テンプレートについて」という文言が表示されますが、ページ生成する際には「テンプレートについて」という文言がcaptionの値に置き換わります。Thymeleafすばらしいですね！
最近仕事で感じる事
私の周りでも最近、デザイナーの方がHTMLやCSSの勉強をされているという話をよく聞きます。 そういったデザイナーさんと仕事すると、この部分を「角丸」という指定でなく「border-radius:3px」とCSSプロパティで指定を受ける事がしばしばあったりします。非常にありがたいことです。
ただそこまで勉強しているのなら、もっと踏み込んでデザイナーさんがいっそ画面部分を作ったらいいじゃん！とも思います。 デザイナーさんも<br>でレイアウトを微調整するような開発者に画面を任せたくないはずです。 (ボックスモデル難しいです)
そこで、Thymeleafの具体的なコーディングの説明は先述の記事にお任せして、以下ではThymeleafを使ってデザイナーさんたちとこんな風に開発していけば業務がうまく回るんじゃないかな、という妄想をしてみました。
静的コンテンツと動的コンテンツの分離
- 静的コンテンツ
- HTTPサーバでさばく
- テンプレート、CSS、JavaScript、画像
- 動的コンテンツ
静的コンテンツもTomcatやGlassFishでさばいた方がパフォーマンスいいよ、という情報を見ますが、あえて分離する方向で話を進めます。ThymeleafのテンプレートはHTTPサーバ側です。
バージョン管理システム上のディレクトリ構成
static配下はまるまるHTTPサーバに配備します。そしてデザイナーさんも編集する領域です。
app配下はwarにしてAPサーバへ。
デザイナーさんにテンプレート(静的ページ）を作成してもらうにあたり、個人的には静的コンテンツを動的コンテンツから分離、独立した方が混乱を招かないのではないかなと感じます。
また、クライアントサイド側の技術もGrant.jsやCompassなど盛り上がりを見せていますね。そういったJavaと無関係のフレームワークを併用する場合、Webアプリケーション内にすべて同梱するのもごちゃごちゃしそうだし、app配下についてはJavaで完結という了解があると後続のJavaエンジニアにも指導しやすい気がします。
TemplateResolverの選択
そして、Webアプリケーション上でテンプレートから動的ページを生成する部分についてですが、Thymeleafにはテンプレートを読み込むTemplateResolverの実装が４つ用意されています。
- ClassLoaderTemplateResolver (クラスパス基準でテンプレート指定)
- FileTemplateResolver (ファイルパスによるテンプレート指定)
- ServletContextTemplateResolver (webアプリケーション階層基準でテンプレート指定)
- UrlTemplateResolver（URLによるテンプレート指定）
この中からUrlTemplateResolverを使用して、HTTPサーバ上からテンプレートを取得する構成にします。HTTP通信してテンプレートを取得するのは若干オーバーヘッドが大きいと思いますが、TemplateResolverにはキャッシュ機能が用意されているので、メモリが十分あればテンプレートを全部キャッシュしてHTTPサーバへのリクエストは初回だけにおさえられます。
（仮に静的コンテンツを分離せずWebアプリケーション内に組み込む構成にするのなら、ServletContextTemplateResolverないしClassLoaderTemplateResolverを利用するのがいいと思います。）
開発の進め方
以上の構成のもと、
- まず、みんなでプロダクトの検討
- デザイナーが静的ページ（画面のモック）を作成。
- 同時にエンジニアがバックエンド側の開発をすすめる。
- デザイナーは静的ページができたら、HTTPサーバにあげて関係者と画面レビュー。
- エンジニアは静的ページに変数を埋め込んでテンプレート化。APサーバでレンダリングしてみる。
- あとは、デザイナーがレイアウト調整したり、エンジニアがJavaScript追加したりバグ潰したり、改修のイテレーション。
おお、いまよりも爆速で開発が回る気がする・・・。いまの私のチームでは、JSPを編集して確認する必要があるためJavaエンジニアが画面作成を請け負います。ただ、デザイナーさんの意図が反映できずに何度も編集しなおしたり、リリース間際になって細部をあきらめたり、作業コストが高めです。デザイナーさんが自らHTMLに落とし込んでくれたら、どんなに素晴らしい事か。
まとめ
以上、Thymeleafを用いた開発体制を考えてみました。エンジニアはアプリケーションの拡張性やレスポンス速度にこだわる一方でデザイナーは画面の余白の持たせ方にこだわるなど、各々こだわりのポイントが異なります。お互いにこだわりを十分に発揮できるような環境があれば良いプロダクトが出来るのではないかなと思いました。
・・・と、数日前この記事を準備していたら、次のホットエントリがあがっていました。
高速にドッグフードを食べるエンジニアと一緒にデザイナーが仕事する方法 - Hatena Designer's Blog
いいなー、うらやましい。
明日のJava EE Advent Calendarの担当はSatoshi Kuboさんです！
続きのエントリです。
