So I''m new to all this Rails stuff and this is probably a database design-related question to, but here it is... Just for learning I''m trying to build a little real estate listings application. Of course there is the listings model which will store basic information like name, price, description, and all that jazz. I''m to the point where I want to figure out how to handle number of bedrooms, garages, heat/air, and stuff like that. I''d like to present those as dropdowns with options in the admin and then of course show the value when viewing the listing. So how do I do it? I see that I could extend my listings model out to have something like bedroom_id in it and then have another model called Bedroom and it have a value column in it. That works fine to show my dropdown. I think I might need to be using some join table for these kind of things, but I don''t know enough about it I guess. Can somebody help me out? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, May 6, 2008 at 5:21 PM, Jeremy <jeremy.bise-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > So how do I do it? I see that I could extend my listings model out to > have something like bedroom_id in it and then have another model > called Bedroom and it have a value column in it. That works fine to > show my dropdown. I think I might need to be using some join table > for these kind of things, but I don''t know enough about it I guess.It would be overkill to introduce models like Bedroom just so you can present a drop-down that contains a list of numbers. However, I''m not at the point in my knowledge of the Rails view stuff where I could recommend the "best" way to do what you want. Perhaps you could use the select_tag helper [ http://www.railsbrain.com/api/edge/doc/index.html?a=M001871&name=select_tag]. The only thing I don''t like about that is that you''d have to put in the view the options for what you want to show. In this simple case, though, that might be a good way to start. Regards, Craig --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Let me just summarize my earlier reply: a simple number_of_bedrooms attribute on the Listing plus the use of the select_tag helper might be a good start. Sorry that I left off the summary and spread this across two replies. Regards, Craig On Tue, May 6, 2008 at 6:25 PM, Craig Demyanovich <cdemyanovich-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > On Tue, May 6, 2008 at 5:21 PM, Jeremy <jeremy.bise-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > So how do I do it? I see that I could extend my listings model out to > > have something like bedroom_id in it and then have another model > > called Bedroom and it have a value column in it. That works fine to > > show my dropdown. I think I might need to be using some join table > > for these kind of things, but I don''t know enough about it I guess. > > > It would be overkill to introduce models like Bedroom just so you can > present a drop-down that contains a list of numbers. However, I''m not at the > point in my knowledge of the Rails view stuff where I could recommend the > "best" way to do what you want. Perhaps you could use the select_tag helper > [ > http://www.railsbrain.com/api/edge/doc/index.html?a=M001871&name=select_tag]. The only thing I don''t like about that is that you''d have to put in the > view the options for what you want to show. In this simple case, though, > that might be a good way to start. > > Regards, > Craig >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
That could be an option...maybe the best. Does anyone else know of a better way before I try it this way? On May 6, 6:29 pm, "Craig Demyanovich" <cdemyanov...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Let me just summarize my earlier reply: a simple number_of_bedrooms > attribute on the Listing plus the use of the select_tag helper might be a > good start. > > Sorry that I left off the summary and spread this across two replies. > > Regards, > Craig > > On Tue, May 6, 2008 at 6:25 PM, Craig Demyanovich <cdemyanov...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote: > > > > > On Tue, May 6, 2008 at 5:21 PM, Jeremy <jeremy.b...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > So how do I do it? I see that I could extend my listings model out to > > > have something like bedroom_id in it and then have another model > > > called Bedroom and it have a value column in it. That works fine to > > > show my dropdown. I think I might need to be using some join table > > > for these kind of things, but I don''t know enough about it I guess. > > > It would be overkill to introduce models like Bedroom just so you can > > present a drop-down that contains a list of numbers. However, I''m not at the > > point in my knowledge of the Rails view stuff where I could recommend the > > "best" way to do what you want. Perhaps you could use the select_tag helper > > [ > >http://www.railsbrain.com/api/edge/doc/index.html?a=M001871&name=sele...]. The only thing I don''t like about that is that you''d have to put in the > > view the options for what you want to show. In this simple case, though, > > that might be a good way to start. > > > Regards, > > Craig--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
In this case, to store the number of bedrooms for a specific place, you should really just use a num_bedrooms field. You don''t need a join table or any model for Bedroom because bedroom doesn''t contain any information. You would only need a Bedroom model if users specified specific information about each Bedroom for instance For instance, if users entered information for every bedroom: type: master space: 500sqft windows: 3 etc then a Bedroom model (linked to the property) would be a great idea. Save that, just use an integer column in the table. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Jeremy wrote:> Can somebody help me out?I''d think that you''d want a generic Room model, and have the type and dimensions be attributes of the room. After all, there is a huge variety in the numbers and types of rooms in any particular dwelling. Something like: Room listing_id (a room belongs to a listing, no?) room_type room_dimensions room_notes (space for stuff like "New Hardwood Floors!" or "New Tile!") + whatever else you decide is important for a room The room type could be served from another model/table. I typically use a model called Reflist to store all my ''reference'' lists that looks like this (with a Reflists model and views, you can easily add to your reference lists, leaving it data driven): # Table name: reflists # # id :integer(11) not null, primary key # ref_type :string(20) default(""), not null # ref_subtype :string(20) # ref_order :integer(11) # ref_name :string(20) default(""), not null # ref_desc :string(45) # created_at :datetime # created_by :string(10) # updated_at :datetime # updated_by :string(10) # lock_version :integer(11) default(0) The ref_type lets me distinguish the type of items ref_subtype is there when I need two levels of categorization ref_order defines the order of the items ref_name is the value I want to store in the referring table (like rooms) ref_desc is what shows in the droplist control room_type in the rooms table would hold some value from the reflist records whose type is ''Room'' In your case, I might define records like: ref_type ref_order ref_name ref_desc ''Room'' 1 ''Living'' ''Living Room'' ''Room'' 2 ''Bedrooom'' ''Bedroom'' ''Room'' 3 ''Dining'' ''Dining Room'' ''Room'' 4 ''Bath'' ''Full Bath'' ''Room'' 5 ''HBath'' ''Half Bath'' etc, etc Droplists in views can be populated with a collection_select to choose the type for each room, like: collection_select(''room'', ''room_type'', Reflist.find(:all, :conditions => ["ref_type = ''Room''"], :order => ''ref_order''), :ref_name, :ref_desc, { :include_blank => true} ) Of course, this is just one approach. Soo many possibilities, so little time... -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Great suggestions, Ar Chron! I was going to suggest something along
the same lines since you really do need to present much more than just
the number of BR (e.g., dimensions) but the number is often an
important search criteria for real estate.
In this case it might be worth checking into Single Table Inheritance
(STI) and creating a generic Room model that is subclassed by Bedroom,
Bathroom, HalfBath, DiningRoom, etc The Listing could then
have_many :rooms, :bedrooms, :bathrooms, :halfbaths, :foreign_key=>:room_id
The reason to do this is that you could fairly quickly:
<label>Bedrooms</label>
<%= @listing.bedrooms.count %>
<label>Bathrooms</label>
<%= "#{@listing.bathrooms.count} Full, #{@listings.halfbaths.count}
Half" %>
You''d also be able to create a useful query for people to find a
listing based on #bedrooms, bathrooms, etc but we''ll leave that as an
exercise for the reader. :)
On May 7, 9:07 am, Ar Chron
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:> Jeremy wrote:
> > Can somebody help me out?
>
> I''d think that you''d want a generic Room model, and have
the type and
> dimensions be attributes of the room. After all, there is a huge variety
> in the numbers and types of rooms in any particular dwelling.
>
> Something like:
>
> Room
> listing_id (a room belongs to a listing, no?)
> room_type
> room_dimensions
> room_notes (space for stuff like "New Hardwood Floors!" or
"New
> Tile!")
> + whatever else you decide is important for a room
>
> The room type could be served from another model/table. I typically use
> a model called Reflist to store all my ''reference'' lists
that looks like
> this (with a Reflists model and views, you can easily add to your
> reference lists, leaving it data driven):
>
> # Table name: reflists
> #
> # id :integer(11) not null, primary key
> # ref_type :string(20) default(""), not null
> # ref_subtype :string(20)
> # ref_order :integer(11)
> # ref_name :string(20) default(""), not null
> # ref_desc :string(45)
> # created_at :datetime
> # created_by :string(10)
> # updated_at :datetime
> # updated_by :string(10)
> # lock_version :integer(11) default(0)
>
> The ref_type lets me distinguish the type of items
> ref_subtype is there when I need two levels of categorization
> ref_order defines the order of the items
> ref_name is the value I want to store in the referring table (like
> rooms)
> ref_desc is what shows in the droplist control
>
> room_type in the rooms table would hold some value from the reflist
> records whose type is ''Room''
>
> In your case, I might define records like:
> ref_type ref_order ref_name ref_desc
> ''Room'' 1 ''Living''
''Living Room''
> ''Room'' 2 ''Bedrooom''
''Bedroom''
> ''Room'' 3 ''Dining''
''Dining Room''
> ''Room'' 4 ''Bath''
''Full Bath''
> ''Room'' 5 ''HBath''
''Half Bath''
> etc, etc
>
> Droplists in views can be populated with a collection_select to choose
> the type for each room, like:
>
> collection_select(''room'', ''room_type'',
> Reflist.find(:all,
> :conditions => ["ref_type =
''Room''"],
> :order => ''ref_order''), :ref_name,
:ref_desc,
> { :include_blank => true} )
>
> Of course, this is just one approach.
> Soo many possibilities, so little time...
> --
> Posted viahttp://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
Good stuff...I may very well implement it this way. If I were simply wanting to store JUST the number of rooms for now, would hard coding the values into the select box be the best way, or is there another best way to store just the number of rooms? On May 7, 10:04 am, AndyV <AndyVana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Great suggestions, Ar Chron! I was going to suggest something along > the same lines since you really do need to present much more than just > the number of BR (e.g., dimensions) but the number is often an > important search criteria for real estate. > > In this case it might be worth checking into Single Table Inheritance > (STI) and creating a generic Room model that is subclassed by Bedroom, > Bathroom, HalfBath, DiningRoom, etc The Listing could then > have_many :rooms, :bedrooms, :bathrooms, :halfbaths, :foreign_key=>:room_id > The reason to do this is that you could fairly quickly: > > <label>Bedrooms</label> > <%= @listing.bedrooms.count %> > > <label>Bathrooms</label> > <%= "#...@listing.bathrooms.count} Full, #...@listings.halfbaths.count} > Half" %> > > You''d also be able to create a useful query for people to find a > listing based on #bedrooms, bathrooms, etc but we''ll leave that as an > exercise for the reader. :) > > On May 7, 9:07 am, Ar Chron <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: > > > Jeremy wrote: > > > Can somebody help me out? > > > I''d think that you''d want a generic Room model, and have the type and > > dimensions be attributes of the room. After all, there is a huge variety > > in the numbers and types of rooms in any particular dwelling. > > > Something like: > > > Room > > listing_id (a room belongs to a listing, no?) > > room_type > > room_dimensions > > room_notes (space for stuff like "New Hardwood Floors!" or "New > > Tile!") > > + whatever else you decide is important for a room > > > The room type could be served from another model/table. I typically use > > a model called Reflist to store all my ''reference'' lists that looks like > > this (with a Reflists model and views, you can easily add to your > > reference lists, leaving it data driven): > > > # Table name: reflists > > # > > # id :integer(11) not null, primary key > > # ref_type :string(20) default(""), not null > > # ref_subtype :string(20) > > # ref_order :integer(11) > > # ref_name :string(20) default(""), not null > > # ref_desc :string(45) > > # created_at :datetime > > # created_by :string(10) > > # updated_at :datetime > > # updated_by :string(10) > > # lock_version :integer(11) default(0) > > > The ref_type lets me distinguish the type of items > > ref_subtype is there when I need two levels of categorization > > ref_order defines the order of the items > > ref_name is the value I want to store in the referring table (like > > rooms) > > ref_desc is what shows in the droplist control > > > room_type in the rooms table would hold some value from the reflist > > records whose type is ''Room'' > > > In your case, I might define records like: > > ref_type ref_order ref_name ref_desc > > ''Room'' 1 ''Living'' ''Living Room'' > > ''Room'' 2 ''Bedrooom'' ''Bedroom'' > > ''Room'' 3 ''Dining'' ''Dining Room'' > > ''Room'' 4 ''Bath'' ''Full Bath'' > > ''Room'' 5 ''HBath'' ''Half Bath'' > > etc, etc > > > Droplists in views can be populated with a collection_select to choose > > the type for each room, like: > > > collection_select(''room'', ''room_type'', > > Reflist.find(:all, > > :conditions => ["ref_type = ''Room''"], > > :order => ''ref_order''), :ref_name, :ref_desc, > > { :include_blank => true} ) > > > Of course, this is just one approach. > > Soo many possibilities, so little time... > > -- > > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On May 6, 9:23 pm, Jeremy <jeremy.b...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> That could be an option...maybe the best. Does anyone else know of a > better way before I try it this way?The only thing I can think of that might be worth considering is acts_as_configurable. This allows you to easily add and remove fields, but without changing the database every time. However, since you are probably going to want to do a search on these fields (i.e. "find me all the houses with 2 bathrooms and 3 bedrooms"), I wouldn''t recommend it. Now, if you have an option with strings instead of numbers, like an enumeration, say for instance floor plan style, or maybe brick vs. wood vs. siding vs. stucco exterior, having a separate join table may make sense. Numbers are much easier to search for and compare than strings, and will be slightly faster. In your app, don''t actually join the table (because then you are back to comparing strings within the joined table), just search for the correct numeral. The join table is just internal documentation to help you remember what each number means. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hard coding isn''t evil, it can just be more difficult to maintain. Rather than hard coding the options into the view, I''d create a constant in the model that contains an options array, e.g., NUMBER_OF_BEDROOMS = [1, 2, 3, 4, 5]. You could then reference this constant in a helper in the view as Listing::NUMBER_OF_BEDROOMS. It might keep your view cleaner. -Kyle On May 7, 9:11 am, Jeremy <jeremy.b...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Good stuff...I may very well implement it this way. If I were simply > wanting to store JUST the number of rooms for now, would hard coding > the values into the select box be the best way, or is there another > best way to store just the number of rooms? > > On May 7, 10:04 am, AndyV <AndyVana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Great suggestions, Ar Chron! I was going to suggest something along > > the same lines since you really do need to present much more than just > > the number of BR (e.g., dimensions) but the number is often an > > important search criteria for real estate. > > > In this case it might be worth checking into Single Table Inheritance > > (STI) and creating a generic Room model that is subclassed by Bedroom, > > Bathroom, HalfBath, DiningRoom, etc The Listing could then > > have_many :rooms, :bedrooms, :bathrooms, :halfbaths, :foreign_key=>:room_id > > The reason to do this is that you could fairly quickly: > > > <label>Bedrooms</label> > > <%= @listing.bedrooms.count %> > > > <label>Bathrooms</label> > > <%= "#...@listing.bathrooms.count} Full, #...@listings.halfbaths.count} > > Half" %> > > > You''d also be able to create a useful query for people to find a > > listing based on #bedrooms, bathrooms, etc but we''ll leave that as an > > exercise for the reader. :) > > > On May 7, 9:07 am, Ar Chron <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: > > > > Jeremy wrote: > > > > Can somebody help me out? > > > > I''d think that you''d want a generic Room model, and have the type and > > > dimensions be attributes of the room. After all, there is a huge variety > > > in the numbers and types of rooms in any particular dwelling. > > > > Something like: > > > > Room > > > listing_id (a room belongs to a listing, no?) > > > room_type > > > room_dimensions > > > room_notes (space for stuff like "New Hardwood Floors!" or "New > > > Tile!") > > > + whatever else you decide is important for a room > > > > The room type could be served from another model/table. I typically use > > > a model called Reflist to store all my ''reference'' lists that looks like > > > this (with a Reflists model and views, you can easily add to your > > > reference lists, leaving it data driven): > > > > # Table name: reflists > > > # > > > # id :integer(11) not null, primary key > > > # ref_type :string(20) default(""), not null > > > # ref_subtype :string(20) > > > # ref_order :integer(11) > > > # ref_name :string(20) default(""), not null > > > # ref_desc :string(45) > > > # created_at :datetime > > > # created_by :string(10) > > > # updated_at :datetime > > > # updated_by :string(10) > > > # lock_version :integer(11) default(0) > > > > The ref_type lets me distinguish the type of items > > > ref_subtype is there when I need two levels of categorization > > > ref_order defines the order of the items > > > ref_name is the value I want to store in the referring table (like > > > rooms) > > > ref_desc is what shows in the droplist control > > > > room_type in the rooms table would hold some value from the reflist > > > records whose type is ''Room'' > > > > In your case, I might define records like: > > > ref_type ref_order ref_name ref_desc > > > ''Room'' 1 ''Living'' ''Living Room'' > > > ''Room'' 2 ''Bedrooom'' ''Bedroom'' > > > ''Room'' 3 ''Dining'' ''Dining Room'' > > > ''Room'' 4 ''Bath'' ''Full Bath'' > > > ''Room'' 5 ''HBath'' ''Half Bath'' > > > etc, etc > > > > Droplists in views can be populated with a collection_select to choose > > > the type for each room, like: > > > > collection_select(''room'', ''room_type'', > > > Reflist.find(:all, > > > :conditions => ["ref_type = ''Room''"], > > > :order => ''ref_order''), :ref_name, :ref_desc, > > > { :include_blank => true} ) > > > > Of course, this is just one approach. > > > Soo many possibilities, so little time... > > > -- > > > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
All valid suggestions, but I don''t think I''ve never seen real estate listings with the kind of information that''s being discussed here. Perhaps if it were a B2B site dealing with new real estate development, but that wasn''t what was described in the original request.> I''m to the point where I want to figure out how to handle number of > bedrooms, garages, heat/air, and stuff like that. I''d like to present > those as dropdowns with options in the admin and then of course show > the value when viewing the listing.num_bedrooms, bedroom_count, or whatever you decide to call it is a simple scalar that will be common to basically every residential property, so creating a Room model is way, way beyond what''s required in my opinion. The same thing can be said of a garage flag (boolean) or number of garage spaces (integer) and most if not all other data fields relating to properties. Given the description provided for this application, going for fourth normal form on a project like this is fine as an exercise, but practically speaking, it''s going to add unnecessary complexity and slow down DB operations and page rendering unnecessarily. On May 7, 6:34 pm, Kyle <kyle.r...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hard coding isn''t evil, it can just be more difficult to maintain. > Rather than hard coding the options into the view, I''d create a > constant in the model that contains an options array, e.g., > NUMBER_OF_BEDROOMS = [1, 2, 3, 4, 5]. You could then reference this > constant in a helper in the view as Listing::NUMBER_OF_BEDROOMS. It > might keep your view cleaner. > > -Kyle > > On May 7, 9:11 am, Jeremy <jeremy.b...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Good stuff...I may very well implement it this way. If I were simply > > wanting to store JUST the number of rooms for now, would hard coding > > the values into the select box be the best way, or is there another > > best way to store just the number of rooms? > > > On May 7, 10:04 am, AndyV <AndyVana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Great suggestions, Ar Chron! I was going to suggest something along > > > the same lines since you really do need to present much more than just > > > the number of BR (e.g., dimensions) but the number is often an > > > important search criteria for real estate. > > > > In this case it might be worth checking into Single Table Inheritance > > > (STI) and creating a generic Room model that is subclassed by Bedroom, > > > Bathroom, HalfBath, DiningRoom, etc The Listing could then > > > have_many :rooms, :bedrooms, :bathrooms, :halfbaths, :foreign_key=>:room_id > > > The reason to do this is that you could fairly quickly: > > > > <label>Bedrooms</label> > > > <%= @listing.bedrooms.count %> > > > > <label>Bathrooms</label> > > > <%= "#...@listing.bathrooms.count} Full, #...@listings.halfbaths.count} > > > Half" %> > > > > You''d also be able to create a useful query for people to find a > > > listing based on #bedrooms, bathrooms, etc but we''ll leave that as an > > > exercise for the reader. :) > > > > On May 7, 9:07 am, Ar Chron <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: > > > > > Jeremy wrote: > > > > > Can somebody help me out? > > > > > I''d think that you''d want a generic Room model, and have the type and > > > > dimensions be attributes of the room. After all, there is a huge variety > > > > in the numbers and types of rooms in any particular dwelling. > > > > > Something like: > > > > > Room > > > > listing_id (a room belongs to a listing, no?) > > > > room_type > > > > room_dimensions > > > > room_notes (space for stuff like "New Hardwood Floors!" or "New > > > > Tile!") > > > > + whatever else you decide is important for a room > > > > > The room type could be served from another model/table. I typically use > > > > a model called Reflist to store all my ''reference'' lists that looks like > > > > this (with a Reflists model and views, you can easily add to your > > > > reference lists, leaving it data driven): > > > > > # Table name: reflists > > > > # > > > > # id :integer(11) not null, primary key > > > > # ref_type :string(20) default(""), not null > > > > # ref_subtype :string(20) > > > > # ref_order :integer(11) > > > > # ref_name :string(20) default(""), not null > > > > # ref_desc :string(45) > > > > # created_at :datetime > > > > # created_by :string(10) > > > > # updated_at :datetime > > > > # updated_by :string(10) > > > > # lock_version :integer(11) default(0) > > > > > The ref_type lets me distinguish the type of items > > > > ref_subtype is there when I need two levels of categorization > > > > ref_order defines the order of the items > > > > ref_name is the value I want to store in the referring table (like > > > > rooms) > > > > ref_desc is what shows in the droplist control > > > > > room_type in the rooms table would hold some value from the reflist > > > > records whose type is ''Room'' > > > > > In your case, I might define records like: > > > > ref_type ref_order ref_name ref_desc > > > > ''Room'' 1 ''Living'' ''Living Room'' > > > > ''Room'' 2 ''Bedrooom'' ''Bedroom'' > > > > ''Room'' 3 ''Dining'' ''Dining Room'' > > > > ''Room'' 4 ''Bath'' ''Full Bath'' > > > > ''Room'' 5 ''HBath'' ''Half Bath'' > > > > etc, etc > > > > > Droplists in views can be populated with a collection_select to choose > > > > the type for each room, like: > > > > > collection_select(''room'', ''room_type'', > > > > Reflist.find(:all, > > > > :conditions => ["ref_type = ''Room''"], > > > > :order => ''ref_order''), :ref_name, :ref_desc, > > > > { :include_blank => true} ) > > > > > Of course, this is just one approach. > > > > Soo many possibilities, so little time... > > > > -- > > > > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---