Template View

Renders information into HTML by embedding markers in an HTML page.

How It Works

カスタムタグ vs それ以外
- カスタムタグ
  - <>はWYSIWYGエディタにより特別扱いされる
- それ以外
  - 【補】{{}}とか
  - タグではないのでWYSIWYGエディタ上でそのまま表示される
    - スペルチェックとかで鬱陶しいかも
Server Page
- ASP, JSP, PHP等
- scriptletsでロジックを書ける
- 大きな問題を孕んでいるので利用を制限したほうがよい
  - better off (忠告)
Template Viewにロジックを書くとここが良くない
- 非プログラマが触れなくなる
  - デザイナーさんとか
- Viewは、ロジックを記述するにはモジュールとしてpoor
- レイヤードアーキテクチャ崩壊
  - ドメインロジックがViewに散らかって重複してしまったりする

条件分岐して出し分けるやつとか
汎用の<IF>みたいなタグを使うのはくさい
- 【補】Laravelでいうと@if - @endif
- 避けられないこともあるが、できるだけ避ける
回避方法1: helperに条件分岐ロジックを移す
- helper戻り値にマークアップが含まれなければうまくいく
- マークアップが含まれる場合は、次のことが犠牲になる
  - WYSIWIGエディタの恩恵にあずかること
  - プログラマとデザイナーとの分業
回避方法2: 単なる<IF>ではないカスタムタグを用意する

これは良くない:

<IF expression = "isHighSelling()"><b></IF>
<property name = "price" />
<IF expression = "isHighSelling()"></b></IF>

こうする

<highlight condition = "isHighSelling" style = "bold">
  <property name = "price" />
</highlight>

Template View styleで書けるのは「server pages」だけではない
- 【補】HTMLを一部place holderで置き換えている・scriptletを実行できるものを言っている
scriptでも書ける
- perlのCGI.pmとか
- 関数コールでマークアップを構築する
  - 文字列結合操作をさける
- 【補】こういうやつ

print $q->ul(
        $q->li('高機能アクセスカウンター'),
        $q->li('RevoCounter')
);

MVCのV
Template View vs. Transform View
Template Viewのメリデメ
- メリ
  - ページ構造を見ながら作り込める
  - デザイナとプログラマとの分業
    - デザイナ: レイアウト
    - プログラマ: helperの実装
- デメ
  - Viewに複雑なロジックを持ち込めてしまう
    - 自制・自律を要する
  - テストしづらい
    - Webサーバーと密結合しているとアプリケーション単体でテストできない
Two Step Viewを採用する場合はTransform Viewのほうが簡単
- 【補】Domain Model XML —XSLT(1st stage)—> Logical Screen XML —XSLT(2nd stage)—> HTML
  - XSLT(2nd stage)を使いまわす

略