横（右）方向へレコードを増やすことができるGrid

[shyba]

お世話になっております。
以下、ご存じの方がおいででしたらご教示いただけると助かります。

通常、Gridはレコードが縦（下）方向へ行が増える動作になると思います。
（cf, 添付「Sample1」）
img1.jpg

これを同一のStoreを使用して、横（右）方向へ列が増える動作として実現させる方法が
ありますでしょうか？
img2.jpg


※便宜上"増える"と表現いたしましたが、動的にレコードが増える必要はありません。



【補足】
１、
添付のSample2をご覧いただければわかると思いますが、Gridへ表示した情報を
Graphへ展開することを考えております。
Graph上へX軸として時系列を表現する為、Gridも横へ時系列を表現させたいのです。
その際、目的用のStoreをそれぞれに生成すれば期待した動作を実現することが
できたのですが、どうせなら同一のStoreで実現できないかという質問です。
（もちろん、グリッド用に作成したStoreで期待するGraphが描画できても問題ない）

２、
「PivodGrid」というコンポーネントで期待する動作を実現できそう（ただし、PivodGrid
本来の使い方とは違うと思いますが）でしたが、4.0.7以降のバージョンでPivodGridは
利用できないのでしょうか？



【動作環境】
OS：Windows7
ブラウザ：Firefox 10.0.2
ExtJS：4.0.7

[mashiki]

私も3.4の時はpivotそのものをつかって、時間軸のように横不定なデータを取り扱う実装を行ったことがあります。

Pivotは次のバージョン4.1でも実装されないようですね。

4からStoreとModelが分離されて少しやらしくなったのですが、
横縦変換を実装してみては？

データ自体はグラフで使っている通常のデータで管理し、
横表示には割り切って、横向きのテンポラリのテーブルを作って表示させようというものです。

http://jsfiddle.net/mashiki/jjjcM/10/

違うStoreに対しても横縦の変換を行うと思いますので、
縦横変換可能Storeをクラスで定義しておけばいいかと思います。
その場合、getReverse()にrowsをローカル変数で定義するのでなくパラメータで渡せば
元の表の形や列数が変わっても対応できるかと思います。

横向きのグリッドを入力用としたい場合、元の表に書き戻しが必要ですが、
ループが１つあるメソッドを書けばいいだけなのでたいしたことは無いでしょう。

ついでに、パネル切り替えもcardを使うように変えてます。ご参考まで。

[shyba]

早速の回答ありがとうございます。

> 4からStoreとModelが分離されて少しやらしくなった

という意図としては、「getReverse」で取得する構造がModelの構造を無視した
形になってしまうといったあたりでしょうか？

とは言え、期待する動作とそのプロセスに関しては私の期待する以上の内容でした。
大変参考になりました。

今回はグリッドへの入力もありませんし、Storeへ格納するデータの量もそれほど
大きくないので、ご教示いただいた方向で進めたいと思います。

ありがとうございました。

[mashiki]

Storeは自分の欲しい物を使うとき、クラスを定義しなくても使えるが、
Modelはクラスを定義しなければなりません。3まではその必要は有りませんでした。

例えば期間条件をを変えて表示ししようとすると、
ゴミのModelを継承したクラス定義が増えていくんですよね。

ざっと見たところdefineしたクラスの削除や同じ名前での再定義は見つからなかったので、
クラス名に連番をつけましたが、繰り返し期間条件もしくはデータを変えて検索されるような
ケースで、クラス定義のゴミがたまってくんですよね。

Storeも見たところ、Modelを差し替えるメソッドは無いのですが、クラスを定義している訳ではないので、
捨てて作り直し、gridはreconfigureメソッドが使えるので、インスタンスを再利用できそうです。

３までは同じstoreに自由にデータを入れられたので、全て使い回せたのですが。
Pivotがでないのも同じような問題がネックになっているかもしれませんね。

[shyba]

ご返信深謝いたします。

> 例えば期間条件をを変えて表示ししようとすると、
> ゴミのModelを継承したクラス定義が増えていくんですよね。

つまり、
「getReverse」の中で指定しているModel『var mdl = 'revModel'+ (++Ext.idSeed)』が
使い捨てになってしまうという意図ですね。
なるほど。納得です。
（「getReverse」の中で指定しているModelを見落としており、もともとのStoreで
　指定しているModel「BPPoint」と「getReverse」で取得される構造が乖離する点を
　言及しておられるのかと勘違いしておりました。）

ご丁寧な解説恐縮いたします。
今後ともよろしくお願いいたします。

[mashiki]

もしかしたら、overrideを使えば、ゴミクラスが増えることも無いかもしれません。
また、Ext.defineでもoverrideできそうなことがドキュメントにちらっと書いてありますね。

使えるのか、繰り返しoverrideしたときにどんな問題があるか判らないですが。

[shyba]

続報ありがとうございます。

直近でどこまで確認できるかわかりませんが、わかったことがあればこちらからもUpするようにいたします。
因みに、

> ドキュメントにちらっと書いてありますね。

に関して、こちらでも少し探してみたのですが該当箇所が見つけられませんでした。
もしよろしければご教示いただけると助かります。

[mashiki]

ここの
http://docs.sencha.com/ext-js/4-0/#!...-method-define

Ext.defineは互いにほとんどaliasだけどうんぬんってとこです。

4.1のドキュメントだとExt.override()は非推奨だからExt.define使えと書いてあり、
Ext.defineも最初の説明でオーバーライドに使えますってはっきり書いてあります。

[shyba]

ご教示深謝いたします。
勉強いたします。

[mashiki]

私も必要になったので少し掘ってみました。

名前空間を汚さずにdefineとreconfigureで行けますね。

http://jsfiddle.net/mashiki/7Kf3a/11/