そうそう、このブログで書いた、ケータイアプリのBREW、PHP、PerlのCGIにおけるMVCモデルの統合とUMLの導入の話と、「BREWでアジャイル」って話は、実はつながっているので、今回は、その話も書いておこうかな。。と。。
あ、あと、i-アプリで応用できそうな可能性についても。。
PHPにおいて、MVCに分けるということは、以前、特集を組んでやってきました。
ちなみに、ここでは、その一覧がリンクされています。
基本的には、PHPの場合、
1.VIEWとなるPHPを作成しておく。
→これは、セッションの値をとってきて、それを表示するだけ
基本的には、HTML
2.コントローラーとなるPHPを作成する。
これは、受け取った値をセッションに入れて、モデルのPHPを呼び出す
モデルのPHPの値(返り値)などにより、次に表示する画面をLocationで呼び出す
その際、必要なら、次の画面で表示する値をセッションにセットしておく
→そーすると、1にいき、セッションから値を見れば表示できる
3.モデル部分のPHPを作成する
セッションから値を受け取り(コントローラーでセットされているはず)
処理したら、次の画面表示に必要な値や結果、次にどの画面を表示するかについての
情報を、セッションにセットする
ということを、繰り返してやるというお話でした。
で、このとき、PHPは、Locationでいくつも呼び出されるけど、セッションの中に、値を入れて、どんどんまわしていくので、当時のJTのCMから、カオル姫方式と名づけました。
基本的に、このMVCは、PERLのCGIでも実現できます
PHPをCGIに変えるだけです。
で、BREWの場合なんですけど、BREWでアジャイルに書いてあるように、1画面につき、
画面名_InitAppData()
画面名_HandleEvent()
画面名_FreeAppData()
というのをつくります。
で、このうち、「画面名_InitAppData()」がVIEWにあたります(というか、VIEWの初期状態に当たります)。
で、「画面名_HandleEvent()」がコントロールになります。
で、モデルは、独自に作っていただくことになります。
初期画面以降の画面変更なのですが、画面部品(テキストコントロールとか)が変わる場合は、別画面と考えます。中身が変わる場合は、このコントローラーから抜ける直前に、領域の値が変わっていたら、もしくは、フォーカスを変える場合、値をセットしてRedrawします(っていうことを、自動的にします)
のこりの「画面名_FreeAppData()」ですが、これはJavaにはない概念(メモリのフリー)で、Viewならず、コントローラー、モデルすべてについて、その画面に関係したもののクリアとなります。
で、カオル姫方式である、画面間、さらにMVC間のデータ保存についてなのですが、はじめにウィザードで作成される構造体
いわゆるpMeに、画面間共通の領域をとっておき、その領域は、アプリ開始時
アプリ名_InitAppData()で作成、アプリ名_FreeAppData()で開放します。
で、さらに、細かい話(画面における部品の持ち方、画面切り替え制御方法)などについて、BREWでアジャイルで触れる予定です。いつやるかわかんないけど、暇になったとき。。
(見る人、すくなそうだったんで)
じゃあ、この方法をiアプリでやる可能性なんですけど、実は、コントローラーって、画面ごとに持っても、アプリで1本でも、部品ごとでも、どーでもいいんです。
なんで、アダプターの形で、部品ごとに、返るところを設定しておいても、だいじょーぶ。
このモデルは使えます。
あと、細かいところに関しては、ウィリアムのいたずらが、暇になったら検討します。
いや、いま、忙しいのよ。。番号振ったり、印刷したり(^^;)
。。って、たいした仕事をしていない(^^;)
で、このMVCモデルの形に落とし込むと、
・VIEWは、結局HTMLで表現でき
(BREWの場合、IHTMLVIEWERを使う)、
・コントローラーは、上記のようにどうでもよく??、
・画面間共通領域が、
PHP、CGIの場合セッション、
BREWの場合、上記のpMeにもつ、共通領域になって、
・あとは、モデルをUMLで作ってもらえばいいことになります。。。
あ、そうそう、UMLのクラス図などで、表現したクラスを、Cでどう表現するか。。。
書いておいたほうがいいかもね(^^)
てなかんじで、この手の話は、今後、関連していきます。
こうごきたい。。なのかなあー??