だいぶデザインコンセプトが固まってきました。最初のプロトタイプはいきなり実装を始めてプログラミングの感覚を取り戻すことにしようかと思っていましたが、それではもったいないのできちんとした設計からやる方針に変えました。きちんと設計を進めてみたところ、今回作ろうとしているのは単に表としてデータを羅列するための役割を持った部品とするよりも、ある情報アーキテクチャに基づいてデータをユーザに公開したり、ユーザからのアクションに対応するためのフレームワークと考えた方がより汎用的です。それに、それぐらいの設計上の敷居をあげておかないとリハビリとしては甘いような気もします。
最初、どれぐらい汎用的なデータモデルを用意すれば、複雑な表にも対応できるか考えるために複雑な表の例を考えることにしました。
まずJTableでも実現できるもっともシンプルなテーブルを考えます。列がいくつかあって、ヘッダがあります。データは一行ごとに表示される形式です。これならばデータの形式はJTableのTableModelのように行ごとに管理するのが良さそうです。セルの結合が多少あっても、それはレンダリングのためのヒント情報を与えてやれば解決できそうです。もう少し複雑な例を考えてみます。
セルやヘッダが結合された上に、ひとつのデータの固まりが複数行を使う場合です。ここでは例として株価情報にしていますが、一件のデータについて表示項目がかなり多くなる場合には、横にデータを広げるよりも折りたたんで、複数行で表現するほうが可読性が向上する場合があります。このような表を扱うような場合、表示上の行と、データ上の行は必ずしも一致しなくなります。JTableのTableModelでこのような表を扱うのはかなり難しくなります。
次の例は、たとえばテーブルの表示幅にあわせて列数が可変になるような表の構造です。この例ではデータは左上の端から右方向に詰め込まれ、表示幅が足りる範囲で右方向に成長します。表示幅が足りなくなれば、次の行に改行します。このような表はショッピングサイトなどのカタログでよく見受けられます。この表のデータモデルは、一次元的ではありますが、表示上の位置関係とは独立したデータモデルとなり、表示位置は動的に決定されます。
さて、表の例としては上記以外にも様々なパターンが考えられますが、様々な形式の表に対応するためには、モデルが多様なデータ形式を受け入れるようにするか、複数パターンのデータモデルを受け入れるようにするなど、いかにも使い勝手が悪くなりそうなにおいのする方向で設計が進みそうです。ここでは、当初のネーミング通り、方眼紙というコンセプトに戻ることにしました。
まずは、もっともシンプルな方眼紙のようなコンポーネントを設計し、それをベースとして多様なデータ表現を実現できるような拡張の形で広げていく方法です。これならば扱うデータモデルの複雑さとAPIとしての使い勝手のバランスがうまくとれそうです。この設計が良いかどうかまだ分かりませんが、あまり設計ばっかり考えていてもリハビリにならないのでだいたいこの方針で、随時軌道修正しながら実装プロトタイプを作っていってみることにします。
