Question

I have the following classes in my ActiveRecord model:

def Property < ActiveRecord::Base
  # attribute: value_type (can hold values like :integer, :string)
end

def PropertyValue < ActiveRecord::Base
  belongs_to property
  # attribute: string_value
  # attribute: integer_value
end

A PropertyValue object is intended to hold only a string value or an integer value, depending on the type, specified in the value_type attribute of the associated Property object. Obviously, we shouldn’t bother the user of the PropertyValue class with this underlying string_value/integer_value mechanism. So I’d like to use a virtual attribute “value” on PropertyValue, that does something like this:

def value
  unless property.nil? || property.value_type.nil?
    read_attribute((property.value_type.to_s + "_value").to_sym)
  end
end

def value=(v)
  unless property.nil? || property.value_type.nil?
    write_attribute((property.value_type.to_s + "_value").to_sym, v)
  end
end

I want to offer the user a view to fill in a bunch of property values, and when the view is posted, I’d like to have PropertyValue objects instantiated based on the list of attributes that is passed in from the view. I’m used to using the build(attributes) operation for this. However, the problem now occurs that I don’t have any control over the order in which the attribute initialization takes place. Thus the assignment of the value attribute will not work when the association with the Property attribute has not yet been made, since the value_type cannot be determined. What is the correct “Rails” way to deal with this?

BTW, as a workaround I have tried the following:

def value=(v)
  if property.nil? || property.value_type.nil?
    @temp_value = v
  else
    write_attribute((property.value_type.to_s + "_value").to_sym, v)
  end
end

def after_initialize
  value = @temp_value
end

Apart from the fact that I think this is quite an ugly solution, it doesn’t actually work with the “build” operation. The @temp_value gets set in the “value=(v)” operation. Also, the “after_initialize” in executed. But, the “value = @temp_value” does not call the “value=(v)” operation strangely enough! So I’m really stuck.

EDIT: build code
I indeed realized that the code to build the Property objects would be handy. I’m doing that from a Product class, that has a has_many association with Property. The code then looks like this:

def property_value_attributes=(property_value_attributes)
  property_value_attributes.each do |attributes|
    product_property_values.build(attributes)
  end
end

At the same time I figured out what I did wrong in the after_initialize operation; it should read:

def after_initialize
  @value = @temp_value
end

The other problem is that the property association on the newly built property_value object will never be set until the actual save() takes place, which is after the “after_initialize”. I got this to work by adding the value_type of the respective property object to the view and then having it passed in through the attributes set upon post. That way I don’t have to instantiate a Property object just to fetch the value_type. Drawback: I need a redundant “value_type” accessor on the PropertyValue class.

So it works, but I’m still very interested in if there’s a cleaner way to do this. One other way is to make sure the property object is attached first to the new PropertyValue before initializing it with the other attributes, but then the mechanism is leaked into the “client object”, which not too clean either.

I would expect some sort of way to override the initializer functionality in such a way that I could affect the order in which attributes get assigned. Something very common in languages like C# or Java. But in Rails…?

Answer 1

Oh jeeezzzz… this is insanely simple, now that I puzzled on it a little more. I just need to override the “initialize(attributes = {})” method on the PropertyValue class like so:

def initialize(attributes = {})
  property = Property.find(attributes[:property_id]) unless attributes[:property_id].blank?
  super(attributes)
end

Now I’m always sure that the property association is filled before the other attributes are set. I just didn’t realize soon enough that Rails’ “build(attributes = {})” and “create(attributes = {})” operations eventually boil down to “new(attributes = {})”.