tonextone.com/note/

Last-modified: 2006-09-01 (金)

Copyright ©master_at_tonextone.com All rights reserved.

MVC2.0 その3

Posted : 2005-12-07 00:00 / Category : [開発日誌]
MVC2.0 その2」の続き。
web2.0 時代の AJAX なウェブアプリケーションにおける MVC について。

AJAX するデータの形式

  • Request(サーバへ送信されるデータの形式)の選択肢:

    1. JSON
    2. XML
    3. PHP/serialize(など、サーバサイド言語固有のデータ記法)

    3. の場合は、XOAD のように、
    サーバサイド言語でクライアントサイドのコードを生成することが前提となるだろう。
    このような密結合は、 web2.0 にはそぐわないと思う。

    クライアントが Flash などの場合も考えれば、
    2.の XML が、やはり最も中立的で、web2.0 的だろう。

    ただ、俺個人的には Flash じゃなくて AJAX やりたいわけだから、
    1.の JSON が俺的ベスト。

  • Response(サーバから返ってくるデータの形式)の選択肢:

    1. JSON
    2. XML
    3. XHTML(部分)
    4. XHTML(全体:クライアントサイドのスクリプトを含む UI 一式)

    4.の XHTML(全体) というのは、AJAX, DHTML などの JavaScript コードを含む UI 全体である。
    web1.0 時代には言うまでも無いことだったかもしれないが、
    web2.0 時代ではクライアントに提供されるのはページ全体だけでは無いので、敢えて明記しておく。

    これ以外の、いわゆる AJAX でやりとりされるデータの形式として、
    3.の XHTML(部分) はどうだろうか?(参考:ahah)
    俺個人的には、(AJAX でない) DHTML も活用したいので、結局 JavaScript で DOM 操作すると思う。
    HTML の動的な要素の管理はクライアントサイドにまとめたいので、
    3.の XHTML(部分) は却下。

    Request と同様、2.の XML が最も web2.0 的だろうが、AJAX やるには JSON で充分。

    ということで、 web2.0 時代の AJAX なサーバは、
    1.の JSON と、4.の XHTML(全体)をクライアントに提供するのが俺的ベスト。

ユーザインターフェイス

  • サーバサイド、クライアントサイドのテンプレートシステムの分担:

    1. multi-page
      サーバサイドのテンプレートシステムは、
      UI のバリエーションを広範囲に担当し、UI 上にコンテンツを展開する。
      UI または、コンテンツを切替える際には、URL の遷移を伴う。

      クライアントサイドのテンプレートシステムは、
      付加的要素のコンテンツ切替えだけを担当する。
      この付加的要素のコンテンツを切替える際には URL は遷移しない( AJAX )。
      DHTML も効果的に使う。

    2. single-page
      サーバサイドのテンプレートシステムは、
      基本レイアウトだけを担当する。
      URL の遷移は必要ない。

      クライアントサイドのテンプレートシステムは、
      UI のバリエーションを広範囲に担当し、UI 上にコンテンツを展開する。
      コンテンツを切替える際にも URL は遷移しない( AJAX )。
      DHTML も効果的に使う。


    1.の multi-page が無難だが、2.の single-page も増えている。
    ( google/ig, live.com, netvibes, ajax-pages )
    ただし、この場合 JavaScript のロードに工夫をしないと、最初の読み込みに相当の時間がかかる。

    multi-page で良いと思うが、
    AJAX なアプリケーションの画面のうち使用頻度の高い画面は、
    single-page 的に(つまり相当の機能をクライアントサイドで実装)したほうが、 AJAX 的ではある。
    (参考: AJAX: Single-page vs. Multi-page)

結論

整理してみると、つまり

 1 画面(URL)毎の自由度が高くなったんだから、
 その自由度によっては、 1 画面(URL)毎の工数はベラボウにかかるかもしれないよ。
 慣れないうちは慎重に進行しようね。
 でも、その分、 画面(URL)数は減ると思うから、
 慣れれば、これまでと同じ工数でできるはず。
 だから頑張れって早く慣れろや。

という事だと納得した。

じゃぁ…こういうフローで行こうかな。
  1. 使用頻度の高い画面を選ぶ。
    (クライアントサイドプログラマ・デザイナ)

  2. その画面の UI を設計する。
    (クライアントサイドプログラマ・デザイナ)

    • その画面に必要な要素を絞り込む。
    • 要素を画面にレイアウトする。
    • 動的要素と静的要素に分ける。
    • さらに AJAX が必要な要素を特定する。

  3. AJAX の I/F を設計する。
    (サーバサイドプログラマ・クライアントサイドプログラマ)

    • やりとりするデータの構造・および形式を決める。
    • AJAX フレームワークを選定する。

  4. AJAX の I/F を実装する。
    (サーバサイドプログラマ・クライアントサイドプログラマ)

    • サーバサイドの AJAXified クラスの I/F を実装する。(ダミーで良い)
    • クライアントサイド から AJAX してみる。

  5. その画面の UI を実装する。
    (サーバサイドプログラマ・クライアントサイドプログラマ・デザイナ)

    • サーバサイドのテンプレートシステムで、
      UI の基本レイアウトの XHTML コードを作成する。
    • クライアントサイドのテンプレートシステムで、
      AJAX のレスポンス(JSON)を展開表示する。
    • UI に効果的な DHTML を導入する。

  6. サーバサイドのロジックを実装する。
    (サーバサイドプログラマ)

    • AJAXified クラスの実装。

  7. 以上を 1画面作成の単位として、必要なだけ繰り返す。

まぁ、こんなところでしょう。

トラックバック

(3)
[ このエントリへはツッコミ出来ません ]