= 設計ポリシー * ベース技術の選択。PHPでSVGを生成してobjectタグで表示する。 * 簡単に扱えるように。お手本は、OpenOfficeのグラフ表示。 * 内部構造、どこまでをオブジェクトとして扱うか。 == ベース技術の選択 以下の選択肢を検討、サーバでSVGを生成して、objectタグで表示する方法を選んだ。 1. サーバでSVGを生成して、objectタグで表示。 1. サーバでPNGを生成して、imgタグで表示。 1. サーバからデータのみをXMLで渡して、JavaScriptで SVG生成、表示。 1. サーバからデータのみをXMLで渡して、Canvas を使って表示。 必須条件としたかったのは、生成したグラフイメージの再利用。つまり、ワープロソフト等に貼り付けて、レポートに利用したかった。 その場合、使い勝手の面では２がベストだが、表示と印刷の解像度の違いから今ひとつであるし、既にかなり多機能なものが世の中に存在するので新たに作る意味がない。 ４は同じく解像度の問題により、却下。 ３は、サーバ側がeasy&smallになるので、言語もPHPだけでなく他にも利用できるとメリットが多いが、各種ブラウザで実験したところ、生成した画像を保存することができない。（2009/7現在） 従って却下せざるを得ない。 == 簡単に扱えるように お手本は、OpenOfficeのグラフ表示。表示方法などで迷ったときは、OpenOfficeではどうなるかを調べて、お手本にする。 使用方法は、できる限り簡単に。 その昔、2001年頃、JpGraphライブラリを使ったことがあるので、使用方法に関しては、その影響を多少なりともうけるだろう。 == 内部構造、どこまでをオブジェクトとして扱うか 何も考えずにすべてオブジェクトにしてしまう方がラク。 しかし、大きな、一見して理解が難しいクラスツリーが出来上がりがち。 オブジェクトにできるものでも、機能が小さなものは、あえてそれをuse するオブジェクトの プロパティー（アトリビュート）として、実装してみよう。 機能や拡張性に難があるものができるかもしれないが、今回は、コンパクトさや理解のしやすさ、実行性能の良さといったメリットが それを上回るような気がする。 だいたい、人が一度に理解できる継承関係・ネストレベル・ヒエラルキー は、3段までぐらいだと思う。「人が」ではなく「私が」かもしれないが。
PSGraph
edit