レヴュー: MasterView - Part 1 MasterViewの長所

RailsのデフォルトのテンプレートエンジンはERBですが、レンダリング結果を見るには実際にレンダリングしてみる必要があります（つまりテンプレートのままではレイアウトなどのデザインを確認できません）。

MasterViewはテンプレート記述言語にXHTMLを拡張したXMLを用いることでブラウザで表示可能にした（つまりWYSIWYG）テンプレートプラグインです。

今回自分のプロジェクトにMasterViewを採用した経験から、３回に分けてレヴューを書いてみたいと思います。

MasterViewの最大の長所、それは表現力のある仕様書を書けること

前述の通り、MasterViewはWYSIWYGタイプのテンプレートエンジンです。MasterViewの詳しい仕組みは次回説明することにして、WYSIWYGの価値について感じたことを書いてみます。

”テンプレートをブラウザで表示できる”。単にそう聞くと、それほど魅力は感じないかもしれません。すぐに思いつくメリットは、”ERBの分からないデザイナーさんとも作業しやすい”などでしょうか。しかし現実的にデザイナーさんはテンプレートの簡単な修正くらいはできるべきだし、そもそも一人で開発する人には関係ないし。”別に、最初から最後までERBでいいよ”という人が大半ではないでしょうか。

ところが実際にXHTMLでテンプレートを書いてみると、想像していなかったメリットがあることに気づきます。それはテンプレートという仕様書の書きやすさ、使いやすさです。

テンプレートは仕様書

テンプレートを「仕様書」と書きましたが、読んで字のごとく、テンプレートは仕様書だと考えられます。プログラミングはコードの一行まで仕様書だという考え方がありますが、同様に、コードのコメント、テストコード、テンプレート、データベースのスキーマも全て仕様書です。

コード／仕様書を書くというのは、頭の中にあるイメージを文書に落とし込んでいく作業です（それ以外の要素もありますが）。イメージを最も良く表現する単語を紙に（あるいはファイルに）書き込んだ瞬間、頭の中に新たな空間がうまれ、それが瞬時に次のイメージで埋められる。そんな経験をしていませんか？この次々と浮かんでくるイメージが開発の効率やコードの質を決めることになります。

だとしたらより良質なイメージを作り出したい。イメージの質をコントロールしたいと思うでしょう。そういう要求があるなら、仕様書は表現豊かであるべきです。紙やファイルに落としたイメージが脳に刺激を与え、次のイメージを作り出す。ブラウザで表示できる視覚的な仕様書は脳に良質な刺激を与えるでしょう（多分）。

視覚的な仕様書は、書くときだけでなく使うときもメリットをもたらします。テンプレートを見ながらコントローラを書く習慣はありませんか？Getting Realによれば「Interface First」ですから、ControllerよりもViewが先にできていても不思議ではありません。視覚的なテンプレートは直感的に次の作業を教えてくれます。

Amrita2との比較

ここまで書いてきたことはMasterViewに限らず、WYSIWYGテンプレート全てに共通の長所です。Rails用のWYSIWYG型テンプレートとしては、MasterViewより以前からAmrita2がありました。ではAmrita2との違いは何でしょうか？

一番の違いは、コミュニティだと思います。MasterViewの開発者Jeff Barczewskiはメーリングリストでまめに利用者の質問に答えており、MasterViewを採用する際に安心感を与えてくれます。

他の違いとしては、Amrita2だとViewに属するコードがControllerに入ってしまうとか。まあこの辺は回避策もあるでしょうし、MasterViewのテンプレートに入ったRubyコードが読みやすいかと聞かれるとはっきり言って疑問なので、どっちもどっちだと思います。

次回はMasterViewのしくみを解説します。