Rails - Jun 2008 - Select with prompt sends blank to validates_inclusion_of?

Hi All, I hope somebody can help.

I''m a bit confused about what would be the best practice for handling
an
enumerated model value with FormOptionsHelper.select +
validates_inclusion_of. Specifically the nil handling.

Some background...

I have an enumerated set of values, which I''m validating using
validates_inclusion_of. Gender (like in the Rails docs example) is
something I have to tackle, but additionally nil is allowed - as there
will be no gender information supplied at initial user registration:

validates_inclusion_of :gender, :in => %w( m f ), :allow_nil => true

An edit profile form will allow gender to be chosen later. In this form,
I''m using FormOptionsHelper''s select with :prompt, so that a
user is
prompted to make a choice if they have not done so yet. i.e. the
model''s
underlying gender value is nil. For situations where a gender has
already been chosen, just the male / female choice is preferred (hence
:prompt seemed a better match to requirements than :include_blank which
always provides a blank option).

The problem is that the gender field "prompt" value gets passed
through
for the gender parameter as blank ("") when no selection is made, but
I''d prefer the value to be left at nil. Rails implementation
considerations aside, if I had a nil value in the model before, and made
no change, I''d expect to retain a nil value after.

So, is :allow_nil of more limited use in validations, for the case where
no input field ever updates the value?

Is it better to opt for :allow_blank => true on any validation where
values are supplied via web form? (I take it that :allow_blank accepts
"" and nil as the blank? method does)

Does anybody go to the effort of translating blank parameter values back
to nils after form submission - and is it worth it?

Any help would be gratefully received. I can''t actually believe I never
stumbled over this one before! I guess enumerated values just feel a bit
different from regular text values, as nil & blank never bothered me for
those. I''m using Rails 2.1 & Ruby 1.8.7

Thanks!
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Jim,

the choice about when to allow null in the database and how to handle
nil in Rails is something I have been pondering of late.  Sometimes
there is a clear reason for doing it one way or another, but in
general, it seems unnclear to me if there is any advantage either
way.

It led me to wondering so I did a bit of googling and came up with
this current discussion which discusses the issue of converting blank
fields to nil - you may be interested in it. (I am bookmarking it for
further thought).

http://opensoul.org/2007/2/7/validations-on-empty-not-nil-attributes

sorry though - I still have not drawn any conclusions - I have been
tending to allow nil on my database columns of late, but I think I
have just convinced myself that that may not be the best approach.

I would be very interested to know if the core team have had any
philosophical considerations about use of nil versus blank, and if so
are there some Rails assumptions that are made, or has anything been
documented. (perhaps it has and I just haven''t found it - I have the
feeling of deja vu, but so much water goes under the bridge)

Tonypm



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---