On Jul 24, 2007, at 2:50 PM, Michael Koziarski wrote:
>
> For dynamic defaults, such as 'the default value for the categories on
> a blog, is taken from the account's default values' I've not seen a
> case that can't be catered for by overriding the initialize method.
>
> Requiring users to call super first is perfectly acceptable to me. To
> expect to use methods from a super class without first initializing
> that super class seems very strange to me.
>
so i'm hacking on this right now, and the issue with this is as
follows, you basically have to do something like this:
def initialize options = nil, &block
super
if options
options.to_options!
unless options.has_key? :some_column
self.some_column = 'some_default_value'
end
end
end
to be robust because otherwise you will clobber a call like this
Module.new 'some_column' => nil
where the user explicitly asks for a column to be nil, or false for
that matter, or used a string key, etc. you can't just check the
value from the db either since that may be false, etc. my point is
that, to me, 'default' in this context means the following: set it
iff the user did not specify it. clobbering, or setting the value
only because it's not a truth value doesn't fit the bill here and
testing whether it was passed in seems a little verbose for what
should be a very easy task.
maybe i am making it over complicated?
cheers.
a @ http://drawohara.com/
--~--~---------~--~----~------------~-------~--~----~
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 rubyonrails-core@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
