特に何もありませんよ～、この記事。小堤です。
さて、考察・・・というかメモというか、なんていうか。
先に書いた、Pluggable MVCの話。さらに色々考えているんですが、なんでこんなことを考えるのか？そもそも、Ext JS自体のコンポーネントモデルで十分じゃないだろうか？
だけど、そうじゃないんだな。
みなさんは、Ext.onReadyに何かきますか？
Viewportのnewですか？BLANK_URL設定ですか？
あくまで、画面に対してExt JSのアプリケーションが1つという前提で構築していませんか？
まぁ確かにそれでもいいのかもしれません。
Ext JSでHTML 上にアプリケーションを構築する場合、2パターンあると思うんですね。
1つは、ViewPortでもいいし、Panelでもいいんですが、Ext JSオンリーのアプリケーション。
もう一つは、既にある画面に対して、装飾、または一部に機能を与えるアプリケーション。
後者は、jQueryなんかでもよくありますね。
どちらの場合も同じですが、アプリケーションとしての初期化処理や、アプリケーションオブジェクトはどうしますか？onReadyで初期化処理するだけで終わりでしょうか？
まぁ、こういうウダウダした疑問からMVCの話があるんですが、コンポーネントモデルに入ってしまうと、はっきり言ってMVC化既にされているとおもうので何もしなくていいと思うんです。Ext JSのコンポーネントモデルを理解していれば。
ただ。アプリケーションとなると、クラス化して、オブザーバブルな機能を提供しないと、アプリケーションが複数ある場合に、それらを連携するのは、イベントリスナーで処理できないと思うんですね。
で、そこだけならもう既に、研究済みでクラス設計もできあがっているんですが、本当にこれでいいのかなぁ・・・というウダウダ。
さらに、Ext.getCmp。これって、いわゆるgotoだと思います。開発をしているとExt.getCmpはインスタンスを保持していない場合など、串刺しでコンポーネントインスタンスを参照できるので、非常に便利ですが諸刃の剣で、gotoと同じようにスパゲティになると思うんです。
おまけに、コンポーネントモデルで設計をちゃんとすれば、コンポーネント単位でテストがしっかりできますが、getCmp使い始めると、単体テストがしにくくなります。
と、こうウダウダいってみると、要するにアプリケーションクラスをしっかり作れば、解決！な気がしてきた・・・。
Pluggableって意味では、コンポーネントにはプラグイン機構があるし、コンポーネント化されてない部分(Observable継承)のものに関しては、必要に応じて継承を行って利用すればいい。
コンポーネントも、継承してメソッドなどにビジネスロジックを記述していくことになる。共通化させたければ、抽象クラス扱いで、コンポーネントを継承して、さらにそれを継承させればいいか。
確かに、Pluggableでモデルクラスをばしばし差し込んでいくと、非常に使い勝手がよさそうなんだけど、Modelクラスの数が半端無くなる。おまけに何が何のモデルなのか、どのために使うモデルなのか訳わかめ。
っていう意味では、コンポーネントモデルはすばらしいわけで、そこはExt JSの仕様に乗るべきだと思う。
前に、ブログに書いたかな？書かなかったかな？間違いなくワークショップでは説明した、Ext JSアプリケーションクラスの作り方。っていうのがあるんだけど、そこら辺をどうしようかという話なんですね。。。
完全、一人ごと。
まぁ・・・いいか、いままで通りアプリケーションクラス作ってやるかぁ。
Adobe Airの場合、セキュリティサンドボックスの関係でアプリケーションクラスを2つ作る必要がある。
そこら辺から派生した話なんだけど、まぁ・・・もうちょい作ってみるかぁ。
