On 22/07/07, Michael Koziarski <[EMAIL PROTECTED]> wrote:
>
> > More importantly though, it's a huge performance hit for any
> > programmer who wants to do something like setting defaults on their
> > object before it gets written to the database, or even checked for
> > validity.
>
> We have before_validation for this case.
No, you don't.
class Foo < ActiveRecord::Base
def before_validate
self.attrib_with_default ||= 99
end
end
p Foo.new.attrib_with_default # nil
The default doesn't get set until the object is about to be validated,
but sometimes you need that default to be set correctly so that you
can use an object before it's either validated or saved. And are you
really suggesting that everyone should call 'valid?' on their objects
if they want them to get their correct defaults set? Default setting
belongs in the initialization phase, not in the validation phase.
> > If the cost of changing the API in this way is deemed too high, please
> > at least consider adding some callback that really is only called
> > after initialization and not after instantiation. It's too useful a
> > place to ignore.
>
> Taking the case of
>
> 1: @customer = Customer.new(params[:customer])
> 2: @customer.do_something
> 3: @customer.save!
>
> What we currently don't have is a hook that will fire before line 2,
> but not when retrieving from a database. Providing defaults before
> validation was a common case, and I believe that's where the
> before_validation hook came from. What other use cases do you have
> in mind?
Well, the obvious case is the case where you're implementing new in
your controller.
The typical boiler plate goes:
def new
@customer = Customer.new
end
That @customer is never going to be validated, but it does make sense
for it to have its defaults (which belong in the model and not the
controller or the view) set correctly so that 'new.rhtml' doesn't need
any knowledge of any default values when rendering the form.
> The name after_initialize is probably a little misleading because it
> fires even when an object is retrieved from the database. Strictly
> speaking this is 'initialization', but from a user's perspective it's
> 'finding' or 'retrieval'. Perhaps at the very least we could give it
> a less confusing, more hazardous sounding name.
But 'after_initialize' implies "call this after you call the
instance's initialize method", and it's apparent that, in the case of
object retrieval, the initialize method simply isn't called (which
makes sense, because the object is only initialized once, when it got
created by calling its class's new method.)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
