Transform View
A view that processes domain data element by element and transforms it into HTML.
-
MVCのVの責務をデータ変換と捉える
- 入力: DomainやData Sourceから取ってきたデータ
- 出力: HTML
How It Works
-
Template Viewとの違い
-
Template View: 出力(HTML)ベース
- データが入るところにマーカー
-
Transform View: 入力要素ごとの変換ベース
- 手続き型で書くとしたら
renderCustomer
とかrenderOrder
といった関数を呼び出してHTMLをレンダリングするイメージ - 各変換は独立しており、変換の適用順に依存しないのが典型
- 手続き型で書くとしたら
-
-
いかなる言語でも記述できるが、書籍執筆時点ではXSLTが主流
-
XMLを変換する関数型言語
-
入力
- XML
-
出力
- HTML
- 別のXML
- CSV
- etc.
-
-
-
XSLTを適用するためには、入力XMLを用意する必要がある
- Domain ObjectをDTOに詰め替えて、DTO自身にXMLシリアライズさせるなど
- データソース層がXMLを返す場合はTransaction Scriptから直接取得してもいい
-
文字列よりもDOMで引き回したほうが高速
- リモートコール時はstringに変換する必要あり
When To Use It
- Transform View vs. Template View
-
Transform Viewのメリデメ
-
デメ
-
Template Viewで使えるような便利なツールが使えない
- HTMLのWYSIWYGエディタ等
- 【補】デザイナーとの分業ができない
-
XSLTの習得がつらい
- 関数型スタイルと、やっかいなXMLシンタックスが組み合わさっている
-
-
メリ
-
XMLのデータソースは何でも良いので、異なるデータソースで共通の見た目にできる
- J2EE
- .NET
-
データソースがXMLの場合、XSLTを使わずに取り回すのは大変
- パースしてデータ構造を走査して…
-
Viewにロジックを詰め込みすぎることがない
- server pageのように任意のスクリプトを書けるような代物ではない
-
テストしやすい
- Webサーバーと切り離してテストできる
-
cf. Template Viewは専用のwebサーバーが必要だったりする
- ASPとか
-
-
-
Webサイト全体の見た目を変えたいとき
- ページごとにデータ->HTMLの変換ロジックが散らばっていると、変更が大変
-
Template Viewよりも変換ロジックを共通化しやすい
- おのずと共通化される、とは言ってない
-
Two Step Viewの適用も検討する
- サイト全体で見た目の変換ロジックを共通化したい
- 顧客ごとに異なる見た目にしたい
英語
-
indulge
- 耽溺する