xFrameworkPX

DirectStore／EditorGridPanel を使ってアプリケーションを作る時の基本的なことを書き留めておきたいと思います。サーバーサイドは，ｘFrameworkPX　を使います。 

 今作っているアプリケーションでは，カテゴリを選択して初めてグリッドに表示する項目が決まるという部分があります。全部で50個ぐらいの項目があるけれど，各カテゴリでは15～20ぐらいになる。他のカテゴリでしか必要のない項目は表示したくない。

ということは，カテゴリを選択してから，Gridの項目数が変わると言うこと。それをどうしたらいいのか，いろいろ考えました。

xFrameworkPXで，Oracleにつないでいろいろやっていました。そうしたら今日，不思議なエラーが発生しました。

 ｘFrameworkPXのモジュールから他のモジュールを参照することはできないのだろうか，ということをいろいろ考えていました。twitterでちょうどリプライをくださった小堤さんにも聞いてみたりして。

でもLiveRecordのメソッドのリファレンスをよくよく見てみると，いろいろなことができるようになっているのが分かります。

テーブルにselect文を発行する際に，もっとも抽象化されているのはsetメソッドです。ExtJsとの相性も良くて，ExtDirectから渡したオブジェクトをそのまま利用してテーブルからデータを取得できます。このメソッドは$usetableで指定されたテーブル（あるいはアソシエートされているテーブル）からデータを取得します。また，他のテーブルをアソシエートする時には，ｘFrameworkPXの場合は必ずしもモジュールを作成する必要はなく，アソシエート対象をテーブル名で指定することもできます。

Ext.DirectとxFrameworkPXでのシステムで，システム利用前に認証を行うという場合を考えます。

一般的なWebシステムの場合，ユーザー名／パスワードでログインすると，セッションにログイン情報が記録され，その後の処理ではセッションでログイン状況をチェックしてから処理をする。というのが一般的な方法だと思います。

Ext Directでの更新処理をやってみたいと思いました。やっぱりExtJSらしいところで，GridPanel（いや更新ですからEditorGridPanelか）で訂正したデータをサーバーに更新をかけるということになります。

サーバーサイドのxFrameworkPXのモデルに更新用のメソッドを用意して，DirectStoreのapiにそれをセットするのかなと思ったのですが，apiの仕様がいまいちよくわかりません。パラメータの渡し方も。ですので，更新をStoreに任せるのではなくて，違う方法での実現を考えました。

※ その後，勉強の甲斐あって，Storeに任せる方法もわかりました。こちらを参照ください＞08.DirectStore でサーバー更新をかける

 さて，Ext.Direct を xFrameworkPX で使うというところにやっとたどりついた。

前回の資料で

• xFrameworkPXにはxFrameworkPX_Controller_ExtDirectクラスが存在する。
• モジュールを作成して、コントローラーに登録するだけでモジュール名でJS側からアクセスできる。
• サーバーサイドのやりとり（api.phpとかrouter.phpの部分）は、ちゃんとオリジナルで実装して動作確認済。
• MVCのModel部分をExt側から透過的に利用できるため、開発が高速。

というのがありました。xFrameworkPX_Controller_ExtDirect を継承したコントローラーを使うと，「モジュール名でアクセスできる」ってことですね。モジュールに必要なメソッドを書いてやれば，それをExt.Directで使えるという訳です。ぐっとハードルが低くなります。

前稿で，モジュールの$this->insert() メソッドについてちらと書いたが，あれはLiveRecordの機能だった。LiveRecordはモジュールのビルトインビヘイビアで，通常のRDBMSに対する様々な処理が実装されているんですね。

引き続き 「データベースの基本的な操作」のチュートリアルを順番にやってみます。

ExtJSの勉強を始めるに当たり，サーバーサイドは，CakePHPでやろうと思っていたが，xFrameworkPX という和製フレームワークを知り，こちらを勉強してみることにした。勉強初日のメモ