関連の話題を取り上げます。皆さんも是非参加してください。昨日も書いたのですが、次の人が出てこないので、今日も書きます。明日はちょっと無理っぽいので、だれかお願いします。フレームワークの中のデータパッケージについての話です。ModelやStoreがサーバーから(いや、クライアントサイドでもですが)データを取得する時には、Proxyを使います。2では、StoreでもModelでも、どちらにでもくっつけられます。Senchaの公式ドキュメントを見ると、どうもModelにくっつける方が推奨されているようです。:このような感じで、Modelにくっつけます。ProxyをModelにくっつけるのと、Storeにくっつけるのでは、どう違うのでしょうか。Modelにくっつけるのを推奨している理由は、次の2つが挙げられていました。StoreがなくてもModel単体でサーバーと通信ができる同じModelを使う複数のStoreがあるときにそれぞれにProxyの設定をする必要が無いなるほど。思って、僕も主にStoreではなくModelにProxyをくっつけて実装していました。それに僕がProxyだったら、StoreとModelを較べるとModelの方がスレンダーで美人なような感じがしますものね(違そして、そんなことを言っていると、ある時にハマりまして、そのときにこの件についてもう一度考える機会を得ました。Proxyってほんとはどっちと結婚したらいいの?(だから違ProxyがModelと結婚したらProxyのコンフィグがセットされたModelがインスタンス化されるときの動きを考えます。Modelというのは、いわばレコードですから、レコードの数だけインスタンスがあることになります。Proxyもそれと同じだけインスタンス化されるのは無駄です、100件も1000件ものModelそれぞれにProxyなんていりません。Proxyのインスタンスは1つしかできません。ModelにProxyのコンフィグがくっついている場合には、そのModelが使うProxyは1つだけ作られます。そのModelのインスタンスが使われる時には、そのProxyが使われます。ProxyがStoreと結婚したらではProxyがStoreのコンフィグにくっつけられていたらどうでしょうか。Storeは、Modelのコレクションです。StoreにProxyのコンフィグがある場合は、Storeがインスタンス化されるごとにProxyのインスタンスも作られ、Storeにセットされます。同じ、Storeクラスからインスタンス化された場合でも、インスタンスが複数作られれば、Proxyも同じ数だけ作られ、Storeにバインドされます。ModelにもStoreにもProxyが設定されていた場合は、StoreのProxyが優先的に使われます。まとめますModelに設定されたProxyのインスタンスは1つだけStoreに設定されたProxyのインスタンスはStoreのインスタンスの数だけこの2つを理解していないとハマる事があります。僕がはまったのは、extraParamsです。これを使って、サーバーにパラメーターを渡してデータを得ていたのです。ProxyはModelにセットしていました。Storeを複数インスタンス化して、別なパラメーターをsetExtraParamでセットして。ここで、勘の良い方はお気づきと思いますが、このやり方だとStoreをいくつインスタンス化しても、Proxyは1つの物が共有されるのです。この図のようになるんですね。setExtraParamでextraParamsの内容を書き換えると、すべてのStoreインスタンスのパラメーターが変わっちまうんです。́・ω・`)このような使い方をする場合は、StoreにProxyをくっつけます。したらStoreインスタンスごとにProxyのインスタンスができるので、extraParamsもそれぞれのStoreで保持されます。以上が、Proxyがどちらを伴侶として選ぶかによって、変わる人生のシミュレーションです(違。深遠な話になりましたね。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。実は僕もちょっとだけ関わっています。2より実践的な内容の第2弾です。実践開発ガイドこの本は、僕が著者になります。