I run a similar approach of normalizing the data to nil (or some base standard) but do it at the model level rather then dealing with the params directly. http://github.com/mdeering/attribute_normalizer Error in the current docs returning from a block but you get the idea.
Cheers, Mike D. On Dec 29, 9:17 am, Chris Cruft <[email protected]> wrote: > Josh nailed it. This issue of empty strings coming back from forms > has been around for eons (in Rails' hyperspeed timeframe). Firing up > the wayback machine, we see this: > > http://dev.rubyonrails.org/ticket/5694 > > BTW, here's my take on a solution using a before filter to recursively > coerce empty strings to nil: > > http://gist.github.com/265388 > > Scratch the HTML forms itch, and perhaps the need for another method > on Object falls below the threshold of irritation. > > One last thought: does Ruby 1.9 provide any guidance here? > > On Dec 28, 1:04 pm, Josh Susser <[email protected]> wrote: > > > This whole discussion is caused by the way Rails handles form > > submissions of text fields. If a user enters no value, the controller > > action gets a param that is an empty string instead of nil. That's > > probably the simplest thing to do in most cases, but the implication > > is that model attributes will have empty strings instead of nil in the > > record. That means you can't do the idiomatic Ruby: > > > user.nickname || user.name > > > Now we have #presence which lets us do: > > > user.nickname.presence || user.name > > > That's reasonably concise, but just keep in mind that all of this is > > just to make Ruby act more like Perl where empty strings are false-ish > > values. I'm sure there are other use cases for #presence, but empty > > strings that come from form submissions seem like at least 90% of the > > issue. > > > --josh > > > On Dec 28, 2009, at 7:07 AM, Rick DeNatale wrote: > > > > On Sun, Dec 27, 2009 at 2:51 PM, Yehuda Katz <[email protected]> wrote: > > >> My biggest concern with nonblank? is that idiomatic Ruby is to > > >> return a > > >> boolean from question mark methods. I like Pratik's solution, and > > >> would like > > >> to see a scenario where the short-circuit logic is important (and > > >> common > > >> enough to justify an core class extension). > > > >> Yehuda Katz > > >> Developer | Engine Yard > > >> (ph) 718.877.1325 > > > > Well IMHO, I think it's more idiomatic Ruby to have a predicate only > > > worry about the truthiness or falsiness of what it returns. Any value > > > other than nil or false is a perfectly good, and true return value > > > from a predicate, and in many cases more useful. > > > > Insisting that a predicate return either true or false, smells more > > > Java or C++ish than Rubyish to me. > > > > But what do I know? > > > > -- > > > Rick DeNatale > > > > Blog:http://talklikeaduck.denhaven2.com/ > > > Twitter:http://twitter.com/RickDeNatale > > > WWR:http://www.workingwithrails.com/person/9021-rick-denatale > > > LinkedIn:http://www.linkedin.com/in/rickdenatale > > > > -- > > > > 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- > > > [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected] > > > . > > > For more options, visit this group > > > athttp://groups.google.com/group/rubyonrails-core?hl=en > > > . > > > -- > > Josh Susserhttp://blog.hasmanythrough.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 [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.
