クライアント側で処理するビューロジック

Ricoを調査しているときに、２つの実現タイプが提供されていて、それぞれいいトコと悪いトコがあると思った。

サーバーからHTMLの断片(を包んだXML)を貰って　innerHTMLを置き換えるパターン
サーバーからXMLを貰って javascript側でデータをビューに変換/マッチングするパターン
- JSON-RPCなんかも似たようなもんかと(乱暴)

後者は一見スマートだし、Google AJAXSLTなんかも基本的には後者の流れを汲むものだという気がするのだけど、これってビューの中にビューを生成するためのロジックを搭載したままクライアントに送り返すわけで、実は気色悪いような気がしている。
いわゆるMVCモデルの話とは別に、"ビューはサーバで生成してクライアントが閲覧するだけ"ということに慣れているのかもしれない。実際にはクライアント側のコンテキストでビューが生成されてもMVCモデルが崩れる、というわけではないだろうから。

そんなわけで私は直感的には前者の方式が好き。サーバから返答するのはHTMLの断片であり、それを愚直にinnerHTML置き換える、というもの。この方式は後者と比べて以下の利点がある。

UIモックからの開発のワークフローが簡潔ではないか
- UIモックの開発時点では動的に置き換わる部分も、まずは静的に書いてユーザーに見せる
- 静的に書いた部分をdivで包んで、そこだけを生成するActionとビューテンプレートを用意すればよい
- 動的に(Ajaxで)置き換わる部分、divやspanの部分だけを生成するAction/jspとかvelocityとか…を用意するのは難しくない
デザイナーとの協業がラクなのではないか
- XMLを受け取ってクライアント側javascriptで「見える」ようにするロジックはデザイナーにはメンテ不可能
- XSLTでも同様
- HTMLならメンテができる
- 動的変更部分だけで Action,jsp/html/velocityなどが完結していればデザイナーは当該部分の見え方だけを変更できる

以下のことについてはイマイチっぽい

サーバ側で Ajax以外のクライアントからのコールも許容する場合、むしろ複雑になる
- ロジックの責務が「見えるビューを返却する」ことに変化しているため
- たとえば「最新の天気を返す」というケースを例に取れば、WebServiceのようにサービスを公開するのと、HTMLビューを返すポイントを公開することでは処理が同じなのに責務が異なる
- ２つ用意したらどうかな...?

以下のことについては差がないか

XMLを返す方式でもXHTMLを返す方式でも、呼ばれる側のロジックの試験単位に差はない
- 出力されたXMLの内容を検証する点で同じ

うーむ。RPCとかWebServiceがらみの話を含めると、よくわからなくなるのだけど、やっぱりAjaxでコールするサーバロジックからはXHTMLビューを返すのがいい気がする。