I have a model that is using the magic "type" field to indicate the
row type for single table inheiritance. In my form I want a
dropdown where the user can select the row type. However, rails
seems to blow up when you use the "select" FormOptionsHelper with a
"type" field:
<%= select(:caregiver, :type, ["Doctor", "Nurse"] ,
{:include_blank
=> true}) %>
When I change :type to :first_name, it works. Has anyone had
success using the form options helper methods with field ":type"?
thanks,
Jeff
On 7/27/05, Jeff Cole <cole.jeff-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I have a model that is using the magic "type" field to indicate the > row type for single table inheiritance. In my form I want a > dropdown where the user can select the row type. However, rails > seems to blow up when you use the "select" FormOptionsHelper with a > "type" field: > > <%= select(:caregiver, :type, ["Doctor", "Nurse"] , {:include_blank > => true}) %>You can''t set an object''s type, an instance has one type and can never change. This is a *huge* indication that you shouldn''t be using inheritance here. Caregiver should probably have a class representing the kind of care giver it is: class Caregiver < ActiveRecord::Base belongs_to :caregiver_type end class CaregiverType < ActiveRecord::Base end Create a caregiver_types table, and put a caregiver_type_id in the caregivers table. Insert a doctor value and a nurse one into the caregiver_types table. Lastly change the view <%= collection_select(:caregiver, :caregiver_type_id, @caregiver_types, :id, :description) %>> When I change :type to :first_name, it works. Has anyone had > success using the form options helper methods with field ":type"? > > thanks, > Jeff > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Cheers Koz
I have a similar issue myself with a table of Images. I have a handful of image "types" for which I planned on using STI (Single Table Inheritance). However, now I am confused. I assumed you were to use STI in cases where you had, what I call, "look-up" tables like CaregiverType. When is it best to use STI vs. type-lookups? thanks -S On Jul 26, 2005, at 4:05 PM, Michael Koziarski wrote:> On 7/27/05, Jeff Cole <cole.jeff-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> I have a model that is using the magic "type" field to indicate the >> row type for single table inheiritance. In my form I want a >> dropdown where the user can select the row type. However, rails >> seems to blow up when you use the "select" FormOptionsHelper with a >> "type" field: >> >> <%= select(:caregiver, :type, ["Doctor", "Nurse"] , {:include_blank >> => true}) %> >> > > You can''t set an object''s type, an instance has one type and can > never change. This is a *huge* indication that you shouldn''t be > using inheritance here. > > Caregiver should probably have a class representing the kind of care > giver it is: > > class Caregiver < ActiveRecord::Base > belongs_to :caregiver_type > end > > class CaregiverType < ActiveRecord::Base > end > > Create a caregiver_types table, and put a caregiver_type_id in the > caregivers table. Insert a doctor value and a nurse one into the > caregiver_types table. > > Lastly change the view > > <%= collection_select(:caregiver, :caregiver_type_id, > @caregiver_types, :id, :description) %> > > >> When I change :type to :first_name, it works. Has anyone had >> success using the form options helper methods with field ":type"? >> >> thanks, >> Jeff >> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> > > > -- > Cheers > > Koz > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Scott Doane wrote:> I have a similar issue myself with a table of Images. I have a handful > of image "types" for which I planned on using STI (Single Table > Inheritance). However, now I am confused. I assumed you were to use > STI in cases where you had, what I call, "look-up" tables like > CaregiverType. When is it best to use STI vs. type-lookups? > > thanks > > -S >STI is generally useful when you have objects that descend from a common parent but then have slightly different data individually. This is easily accomplished with OO but becomes a slight pain when you try to store it in a rdbms. As an example, I recently had an STI table containing organisations. The majority of the organisations were the same but a couple had one additional field each. The organisations table itself had all of the fields for all types of organisation but the models for the different types of organisation were geared towards the specific type of organisation. In your example, would the image_type of a given image ever alter the image model, i.e. add more data? If not, then you just need a lookup table with a one to many relationship between the two (i.e. image belong_to :image_type and image_type has_many :images). If the image_type does change the data for an image (think fields in database) then you are correct in your use of STI. Chris PS. I managed to refactor out my use of STI by giving the additional fields vague enough names that they could be applied to any organisation.
On 7/27/05, Scott Doane <psifire-ee4meeAH724@public.gmane.org> wrote:> I have a similar issue myself with a table of Images. I have a > handful of image "types" for which I planned on using STI (Single > Table Inheritance). However, now I am confused. I assumed you were > to use STI in cases where you had, what I call, "look-up" tables like > CaregiverType. When is it best to use STI vs. type-lookups?If you ignori the specifics of STI, and focus on general inheritance my advice is: "Almost never inherit. Composition is almost always the better option." The fact is, you can''t change an object''s class. So the caregiver example is perfect, don''t use inheritance. The common Customer < Person example falls down here too. If you have Customer < Person, and Staff < Person what do you do about customers who are staff members? -- Cheers Koz
Originally I implemented this with a caregiver_type table, but I thought the STI was cleaner. Although the data I store will be similar for these different caregiver types, their behavior is slightly different--each would have custom implementations of common Caregiver methods. If I use a caregiver_type table, then I have to implement those methods with big "select case caregiver_type_id" to implement the proper behavior inside them. Seems more kludgey than having different classes for each caregiver type. -Jeff On Jul 26, 2005, at 4:05 PM, Michael Koziarski wrote:> On 7/27/05, Jeff Cole <cole.jeff-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> I have a model that is using the magic "type" field to indicate the >> row type for single table inheiritance. In my form I want a >> dropdown where the user can select the row type. However, rails >> seems to blow up when you use the "select" FormOptionsHelper with a >> "type" field: >> >> <%= select(:caregiver, :type, ["Doctor", "Nurse"] , {:include_blank >> => true}) %> >> > > You can''t set an object''s type, an instance has one type and can > never change. This is a *huge* indication that you shouldn''t be > using inheritance here. > > Caregiver should probably have a class representing the kind of care > giver it is: > > class Caregiver < ActiveRecord::Base > belongs_to :caregiver_type > end > > class CaregiverType < ActiveRecord::Base > end > > Create a caregiver_types table, and put a caregiver_type_id in the > caregivers table. Insert a doctor value and a nurse one into the > caregiver_types table. > > Lastly change the view > > <%= collection_select(:caregiver, :caregiver_type_id, > @caregiver_types, :id, :description) %> > > >> When I change :type to :first_name, it works. Has anyone had >> success using the form options helper methods with field ":type"? >> >> thanks, >> Jeff >> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> > > > -- > Cheers > > Koz > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >