tonextone.com/note/

「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画面作成の単位として、必要なだけ繰り返す。
   

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

「MVC2.0 その1」の続き。
web2.0 時代の AJAX なウェブアプリケーションにおける MVC について。

良さげな AJAX ライブラリを比較

PEAR::HTML_AJAX と XOAD とを比較する。
HTML_AJAXは、昨日 0.3.1 が出たらしいので、

$ pear install "channel://pear.php.net/HTML_AJAX-0.3.1"

XOAD は普通に一式サーバにアップロードで OK 。

共通点

共通点を説明するために、勝手に用語を導入する。

AJAXify

サーバサイドで定義されたクラスを AJAX 的に利用できるようにする事を「AJAXify」と呼ぶ。
HTML_AJAX, XOAD では、
サーバサイド(PHP)で定義されたクラスを
クライアントサイド(JavaScript)からコールする際に必要な、
クライアントサイドのコードを自動生成する機能を提供している(Sajax, JPSPANも同様)。
これを「AJAXify」ユーティリティと呼ぶ。
HTML_AJAX では、この機能の事を proxy と呼んでいるらしい。
HTML_AJAX の作者の blog 'There and Back Again'では mapped_functions とか呼んでいる。

簡単なクラス( _String.class.phps )を AJAXify してみると、当然似たようなコードになる( コードの比較 )。
動作デモはこちら。 HTML_AJAX, XOAD.

相違点

1. HTML_AJAX の「AJAXify」ユーティリティは、
   クライアントサイドの「AJAXified」クラス(プロトタイプ)をサーバサイドで自動生成するので、
   プログラマはこのクラスから「AJAXified」インスタンスを生成する JavaScript コードを書く。
   この際、コンストラクタの引数としてコールバックオブジェクトのインスタンスを指定する。
   

   <script>
   var object = new _String(callBack);
   var anotherObject = new _String(callBack);
   </script>
   <button onClick="object.returnFromPHP('JS> how are you?\n')">click!</button>
   <button onClick="anotherObject.returnFromPHP('JS> again, how are you?\n')">click!</button>
   

   一方、XOAD の「AJAXify」ユーティリティは、
   クライアントサイドの「AJAXified」インスタンスをサーバサイドで自動生成するので、
   プログラマはインスタンスを生成する JavaScript コードを書かない。
   その代わり、「AJAXified」インスタンスのメソッドの引数にコールバック関数を指定する。

   <script>
   var object = <?= XOAD_Client::register(new _String()) ?>;
   var anotherObject = <?= XOAD_Client::register(new _String()) ?>;
   </script>
   <button onClick="object.returnFromPHP('JS> how are you?\n', callBack)">click!</button>
   <button onClick="anotherObject.returnFromPHP('JS> again, how are you?\n', callBack)">click!</button>
   

   
   
2. HTML_AJAX では、 server.php

   <?
   include_once('HTML/AJAX/Server.php');
   $server = new HTML_AJAX_Server();
   /*
    * 必要ならここでいろいろ設定。
    * でもどんな設定ができのか不明。
    */
   $server->handleRequest();
   ?>
   

   とか言うのを作って置く必要があるが、
   XOAD では不要。
   
   
3. HTML_AJAX では、

   <?
   $ajax =& new HTML_AJAX();
   $ajax->registerClass((new _String()),'_String',array('returnFromPHP'));
   ?>
   

   みたいに、クラス名、メソッド名のマッピングも「AJAXifiy」と同時にできる。
   
   一方、XOAD では、

   <?
   XOAD_Server::allowClasses('_String');
   ?>
   

   で済むんだけど、その代わり「AJAXify」したいクラスに、

   <?
   class _String
   {
     /* snip */
   
     function xoadGetMeta()
     {
       XOAD_Client::mapMethods($this, array('returnFromPHP'));
       XOAD_Client::publicMethods($this, array('returnFromPHP'));
     }
   }
   ?>
   

   みたいにメソッド名をマッピングするメソッドを追加する必要があり、ちょっとウザい。
   
   
4. HTML_AJAX では、
   XMLHTTPRequest で送信されるデータ、サーバから戻ってくるデータ共に、

   <script>
   HTML_AJAX.defaultEncoding = 'JSON';
   </script>
   

   で指定したエンコーディングが使われるらしい。
   'JSON' 以外のオプションは 'NULL' って言うのがあるけど、それ以外は不明。
   
   一方、 XOAD では、
   XMLHTTPRequest で送信されるデータは PHP の serialize(); 形式、
   サーバから戻ってくるデータは JSON。
   POST を監視するとこんなのがサーバに飛んできました。

   a:4:{s:6:"source";s:18:"O:7:"_string":0:{}"; \
        s:9:"className";s:7:"_string";s:6:"method";s:13:"returnFromPHP"; \
        s:9:"arguments";s:35:"a:1:{i:0;s:17:"JS> how are you?";}";}
   

   JavaScript で、 XOAD.serialize(); している。
   お互いに相手に合わせてる感じ(笑)。良いのか悪いのか。
   
   
5. ちなみに、クライアントライブラリとして読み込まれる JavaScript の行数は、
   HTML_AJAX : 2681
   XOAD : 611
   
   

考察

疲れたので、一服してから別エントリとして。

参考URL

[HTML_AJAX]
HTML_AJAX 作者の方によるスライド
HTML_AJAX 作者の方の関連記事
多分同じ人によるexamples

[XOAD]
公式ページ

「PEAR その1」の続き。

web1.0 系

1. Auth は「帯に短し」。
2. Mail_Mime は普通に使える。

web2.0 系

1. HTTP_Request は個人プロジェクト(sparQuery)などで使っている。
   HTTP_Client より API の抽象化レベルが低いので、そのぶん強力。
   これからも使うだろう。
   
2. XML_Serializer も上記プロジェクトなどで使っている。
   XML_RSS より API の抽象化レベルが低いので、そのぶん強力。
   これからも使うだろう。
   
3. XML_RPC はこれからも自発的には使わないだろう(SOAP も同様)。
   サーバ間通信は REST でお願いします。
4. HTML_AJAX は思ったより良さそう。
   クライアントサイドから呼び出すクラスを登録(HTML_AJAX::registerClass(new SomeClass());)しておけば、

   <script>HTML_AJAX.call(SomeClass, someMethod, callBackFunc, arg1, arg2, ...);</script>

   とするだけで、サーバサイドの

   <? SomeClass::someMethod($args); ?>

   を呼び出せる。
   こういうのを RPC とか mapped-function とか言うのだと思っている。
   上記プロジェクトでは Sajax を使っているが、基本的に同様のものだ。JPSPAN も同様。
   ただ、Sajax も JPSPAN も、開発が停滞しており、
   HTML_AJAX と XOADとを、後継候補として検討中。

明日は、「MVC2.0 その2」として HTML_AJAX と XOAD との試用レポートを書く予定。

PEAR との付き合い方を探っている。
これまで使った事があるもの:

1. 誰が作っても同じ API になりそうな比較的堅いもの。
   ( HTTP_Request など)
2. 自作するには労力がかかりすぎるもの。
   ( XML_Serializer など)

つまり、いろんな意味でブラックボックスとして扱いたい単機能は PEAR で充分。
逆に、開発のモチベーションに直結する機能、ブラックボックスでは困る機能に関しては、
自作ライブラリを使って来た…と言える。今にして思えば。

大きめの開発の立ち上がりは、いつもライブラリ/フレームワークの設計から始めていた。
フレームワークの開発自体に面白味を感じていたからこそ、そういうスタイルでやって来たわけで、
それが今では自分の力になっている。
一人で開発・メンテナンスするなら、それで良いと思う。

ただ、これからは、いろいろとオープンにしたいので、
まぁ共通語としての PEAR を読み書きくらいは出来るように勉強中。

今日のメモ:

1. PEAR に channel:// という概念が導入され、
   レポジトリを切替えてパッケージ管理できるように?なったらしい。
   

   $ pear config-show;

   してみると、デフォルトの channel なんかが見れる。

   $ pear upgrade 'channel://pear.php.net/XML_Serializer-0.18.0';

   とか使う。
2. DB は抽象化クラス。
   DB_DataObject は O/R マッパークラス。
   基本的な部分しか試してないけど、分かりやすい。
   O/R マッピングってこういうことか…。
   O/R マッパーじゃないけど似たような使い勝手のライブラリ
   (非オブジェクト指向)を自作してあるので早くも興ざめ。
   

次は、Auth, Mail_Mime を。
さらにその後は web2.0 な、 HTTP_Request, XML_Serializer, XML_RPC, HTML_AJAX で遊ぶ予定。

自ドメインのメールアドレスをいくつか使用している。
でも、このサーバには SMTP サーバ( qmail )は立ててるけど、POP サーバは立ててない。
だって面倒。
で、どうしているかというと:

1. Reply-To: <[email protected]> ヘッダをつけて送信する。
2. [email protected] 宛てのメールは dot.qmail-foo で、[email protected] に転送。

基本的にこれだけなんだけど、POP に proxy を 2 段ほど刺している。 Norton AntiVirus と POPFile。

PC 環境を再構築するハメになってみて、この辺の設定がメンドかったのでメモ。
( OutlookExpress の場合です)





百聞は一見に如かず。