世の haml の紹介では html って閉じタグが無いからすっきり書けるよ!とか.Hogeって書くだけで<div class="Hoge"> になるよ!簡単!みたいなレベルで紹介されているが、haml の真価はそんなところにはないと思っている。haml が本当にすごいと感じるのは、view を作るための簡易 DSL を定義できるところにあると考えている。理想的には、html タグを一切かかない view、ということになる。(もちろんそのような原理主義的なやり方はうまくいくはずがない)。
世の中で紹介されている、haml すげー!という解説はこんな感じ。
%div.SearchForm
名前
%input{:type=>:text, :name => :name}
生年月日
%input{:type=>:text, :name => :birthday}
上げられる利点は
- 閉じタグ書かなくていいよ
- クラスとかIDが簡単に設定できるよ
- 見た目上我々が認知するブロック構造と haml の構造が良く対応している
- 全てのタグ(haml行)は単なる checkbox や div よりもビジネスロジック上やUI上リッチな意味を持つ(論理タグと呼ぶ)
- ビジネスロジックやUI上意味を持たない余計な html タグ(物理タグと呼ぶ)があまり現れない
適当にでっちあげた例だが、例えば以下のようなものだ。
- search_form do
- left do
- search_field :name
- search_field :email
- right do
- search_field :birthday
- search_field :user_type_id
- buttons do
- clear_button
- csv_download_button
- submit_button
この例では検索フォームを記述するときに、フォームの左側と右側にそれぞれ何を書くか。サブミットボタンの部分に何を書くか、という設定をする。それ以外の枠組みは search_form というメソッドが書いてしまう。
あるいは、タブ形式の入力画面は以下のようになる。
- tabs do
- tab "基本情報" do
- input :name
- input :kana
- input :email
- tab "住所" do
- input :zip_code
- input :address
ラジオボタンの選択結果によって入力できる場所が切り替わる(入力できない場所が disable されるようなもの)を書くときは
- exclusive do
- choice "メールで連絡を希望" do
- input :email
- choice "電話で連絡を希望" do
- input :tel
のようにする。
このようにすることで記述量を劇的に減らすことができるし、一行当たりの意味の濃度が圧倒的に高いので理解もしやすい。UIの要素ごとにきれいにコードの共通化が行われているため、品質の一定化が容易だし、変更にも非常に強い。
ただ、ほかでよく指摘されているように、デザイナーさんとの協業は相性が悪い。業務アプリのような、ページのコンポーネントが限られていて、かつデザイン上後から手を加えるようなことが少ない場合に使いやすい。私はもっぱら業務アプリに使っている。twitter bootstrap と組み合わせると非常に効果的だ。
また同様に、この DSL が動きだすまでの最初の準備にはかなり手間がかかる。そのため短期のプロジェクトではあまりペイしない。ここも twitter bootstrap でうまく組み合わせることでプロジェクトをまたがった再利用ができるようになると思う。
個人的にはさらに cucumber の用語とすり合わせることでテストが簡単に書けるようになるかなぁと考えている。
0 件のコメント:
コメントを投稿