Have to be missing something simple here…
The select helper methods include the option to dynamically add a
“Please select” item or simply a blank to the top of the list, as in
select(“post”, “category”, Post::CATEGORIES, {:include_blank => true})
When this field is not required and a user leaves it as is and submits
the form, it sends back an empty string to the controller, which
unfortunately gets converted to a 0 if the field type is an integer (as
in the case of a foreign key). As a result, you get a 0 in the database
instead of a null, so that when you invoke the form again, the first
value in the dropdown is selected - obviously incorrect. The underlying
problem in part is that “”.to_i and nil.to_i both return 0. (BTW, the
database columns in question can accept nulls)
We are currently doing a hack to remove the values in the controller
action, but is there a better way?
TIA,
Keith
So…based on the overwhelming response… nobody else seeing this as
an issue? Removing the offending values in the controller is the best
way to go?
Keith
On 9/7/06, Keith L. [email protected] wrote:
unfortunately gets converted to a 0 if the field type is an integer (as
in the case of a foreign key). As a result, you get a 0 in the database
instead of a null, so that when you invoke the form again, the first
value in the dropdown is selected - obviously incorrect. The underlying
problem in part is that “”.to_i and nil.to_i both return 0. (BTW, the
database columns in question can accept nulls)
We are currently doing a hack to remove the values in the controller
action, but is there a better way?
Can’t use a validation in your controller for this field?
Michael C. wrote:
On 9/9/06, Michael C. [email protected] wrote:
the form, it sends back an empty string to the controller, which
Can’t use a validation in your controller for this field?
Gah, of course I mean “model” there, not “controller”.
We can, IF we do custom validation. Part of the problem (which we’ve
seen in other areas) is that Ruby coerces nil or blank strings (“”) to
0. The standard validator, for example, validates_numericality_of, will
let a 0 (zero) go through just fine.
Keith
On 9/9/06, Keith L. [email protected] wrote:
seen in other areas) is that Ruby coerces nil or blank strings (“”) to
0. The standard validator, for example, validates_numericality_of, will
let a 0 (zero) go through just fine.
Still, that shouldn’t be too difficult, right?
def validate
if self.whatever == 0
…
On 9/9/06, Michael C. [email protected] wrote:
the form, it sends back an empty string to the controller, which
Can’t use a validation in your controller for this field?
Gah, of course I mean “model” there, not “controller”.
On 9/9/06, Keith L. [email protected] wrote:
def validate
if self.whatever == 0
…
True. Guess that’s what we will do - seems cleaner than trapping things
in the controller the way we have been , although still seems a bit
clunky…
I’m still not completely comfortable with validations in the model; no
reason for that, just my MVC upbringing that always did that sort of
thing in the controller. I’m getting used to it though.
Anyway, thanks for the assist.
Glad I could help!
Michael C. wrote:
On 9/9/06, Keith L. [email protected] wrote:
seen in other areas) is that Ruby coerces nil or blank strings (“”) to
0. The standard validator, for example, validates_numericality_of, will
let a 0 (zero) go through just fine.
Still, that shouldn’t be too difficult, right?
def validate
if self.whatever == 0
…
True. Guess that’s what we will do - seems cleaner than trapping things
in the controller the way we have been , although still seems a bit
clunky…
Anyway, thanks for the assist.
Keith