データの型としてのコンボボックス

Rails1.2でのマイグレーションのコードを書こうとしています。

 

class CreateMemos ＜ ActiveRecord::Migration

  def self.up

    create_table :memos do |t|

      t.column :tittle, :string

      t.column :info_source, :combo_box   ----- (1)

      t.column :description, :text

      t.column :photo_uri, :url ※

    end

  end

  def self.down

    drop_table :memos

  end

end

(1)で、データが何でコンボボックスに限定されるのか？それは可笑しい、というのが今までの考え方だと思います。私（か誰か他の人）が実現しない限り、それは正論でしょう。こういうコードを書きたければ（少なくともRails1.2では）自分で別なテーブル..info_sourcesを定義して、そのID...info_sources_idを定義し、それに対してhas_many、belongs_to 交換を行なう必要があると思います。そもそもコンボボックスかどうかはモデルには関係ない話で、関係させてはいけない、というのが常識だと思います。

しかしこれは、私もいま気づいてメモしているわけですが、実際にあるページをテンプレートにするという考え方と同じです。※これについてはブログエントリしてないかもしれません。

つまり、コンボボックスとして使うために普通あるべきデータの形、と読み替えることができます。その結果、コンボボックスで表現するに相応しいデータ形式が選ばれるのです。ですから、実際にページになるときに、それがリストボックスでも構いません。ただ、データを設計する（考える）という場合に何が重要で何が元になるかと言えば、どんな風なページにしたいかであることは言うまでもありません。ラフで書いたイメージ通りにデータが定義されれば、こんなに便利なことはないのです。

コロンブス的に言えば、みんな１つのUI部品を仮定すると、それが絶対的なものと思い込んでしまっていることでしょう。コンボボックスを右クリックしてリストボックスに変更できて、何か不都合がありますか？　もちろん縦長になる分レイアウトは崩れるでしょうが、リストボックスにしたいのですから、そんなことぐらい分かっているはずです。

これが概念交換機の姿なのです。

ただしRailsに組み込もうとすると、もっとRailsを詳しく知らなければならないでしょうし、組み込めるかどうかもわかりません。通常のオブジェクトとしてならまだしも、combo_boxを受けた側は一体どうすれば良いのか。CoC風にはinfo_sourceという名前からinfo_sourcesというテーブルを作成し、項目はデフォルトの_idとTitleぐらいを付けて、InfoSourceクラス（モデル）にhas_many ,  Memoクラス（モデル）にbelongs_to info_source_idを追加するという感じです。しかしすでにあるソースに行を追加するという芸当がRailsで出来るのか、という問題もあります。それならMashupEX!にRailsEX!を入れるというのが、やはり定石でしょう。

※は探すとRails2.0でこういう記述を見かけたことがありますが、私はまだ1.2なせいか、エラーになってしまいます。Rails本ではStringか何かで定義されていたと思います（間違ってたらごめんなさい）。