Xxxx_before_type_cast and form_helper methods

Can anyone explain why the _before_type_cast method is
called in the constructor of InstanceTag such that all of the form
helper methods use the “uncast” attribute value?

I know there’s a reason but have no idea what it is.

Thanks,
Wes

This is kind of annoying as I have a different format that I want to
display my form fields with and I have to use a helper now to do the
formatting instead of being able to handle it in my model object.

Anybody know why xxx_before_type_cast is used?

Wes

Maybe there should be a way to disallow overriding the attribute getters
since they aren’t used by the form_helpers anyway. That probably
doesn’t make sense, but…

I’ve “re-discovered” the fact that xxx_before_type_cast is used to pull
the attribute values for form helpers at least 5 times in the last 2
months because it is so non-intuitive. I really have to question this
behavior.

It seems like if I want to modify an attribute “on the way out” of the
database that I should be able to do that without having to resort to
another attribute. It feels very natural for me to override the
accessors (very OO) so this is why I keep forgetting that it doesn’t
work.

Apparently, the argument for using _before_type_cast has something to do
with these accessor methods doing conversions on the input data and then
the form input value being changed “out from under” the user. Why can’t
we as users just be responsible for making sure that doesn’t
happen/handling our own data conversions?

I have the opposite problem - I want to store my data in a different
format in the database than my display format and so I want to
translate on the way in and out.

We already have the ability to use read_attribute(:attribute_name) when
we want to get the database value of the attribute. Why do we need AR
to force this type of access on us?

My gut feeling is that AR may only be called an OR mapping nominally
since certain access paths and initialization are non-standard.

Thanks,
Wes

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs