« Bフレッツ+プロバイダの申し込み | メイン | 書類到着 »
2004年10月31日
キリカ・グライト開発日誌:: 属性設定用UI
Tweet @jin1016をフォローコマンドメニューで残っていた分を追加。メニューだけでも面倒なのに、UIとなると･･･
UIはいくつかは使い回せたり、属性なしも結構あるからだいぶマシかもしれないけど。
属性設定用のUIを作っていく。やっと10個分だ。
このUIとグリッド部、ドキュメント部とのハンドリングについて考える。
以前も何か考えていたなぁと思い、クラス図を見るとやっぱり考えていた。
しかし、そのときはModel/Observerを知らなかったので、単なるクラスとして考えていた。
なので、再考中。
基本的なやりとりは、スクリプトを介すことで汎用的なインターフェイスにしようと思ったが、UIのいくつかは共通化している。
共通化しているUIは単なる有効/無効、ファイル選択だけを属性に持つものだ。
共通化しているUIで異なるスクリプトになるのもある。
クラスを受け渡し！この文章を書いていて気付いた。
文書化は告知や報告など以外に思考の整理としてなかなか役立つ。
誰かに何かを説明しようとしたら当然理路整然としていなければならない。頭の中では筋が通っていると思いこんでいるものは意外と多い。
文章化すればこのような矛盾に気付く。
また、なぜか新しいアイデアなどが思い付くこともある。
人に説明しようとすることはいろいろと役立つことが多い。
話がそれてしまったので元に戻そう。
グリッドと属性設定UIとのやりとりはクラスを受け渡す方法にしよう。
パラメタを持つクラスは1つのクラスから派生させれば、インターフェイスは共通化できる。
ドキュメントの方とはどうするか？
同じような方法をとっても良いが･･･ バケツリレーのような方法でやろう。
つまり、属性設定UI→グリッド→ドキュメントといった具合に受け渡していく。
属性設定UI、グリッド間はクラスでやりとり、グリッド、ドキュメント間はスクリプトとしよう。
グリッドは直接スクリプトを編集することも出来るようにするのでその方が都合がよい。
構造を考えていくと、グリッドがドキュメントへのアクセスを一手に引き受ける形になりそうだな。
I/Oは限定されている方がやりやすい。
投稿者 Takenori : 2004年10月31日 11:50
comments powered by Disqus