It's not a prototype thing. A blank option will submit a blank value
which Rails converts to nil. You're better of checking for the nil
using validation or manually in your action and returning an error
message.
It kind of sucks, because the params in question are being
automatically appended to the where clause in a select. In the case of
the blank option, I don't want to return an error. Its a perfectly
valid choice by user. It means "no where criteria". But because the
"nil" value is being propagated, I'm getting stupid stuff like "where
city_id = NULL" in the select.
Everything was code free and elegant up to this point. Now I will
have to intercept every request check for these edge cases in the
params and remove them. All of the elegance just broke down.
I'm using ActiveScaffold. It has a collection of Ajax enabled .rhtml
templates and helpers which collectively peform a lot of magic. Very
powerful but not easy to follow.
Anyway, the List scaffold page includes a Search form with a single
text field.. When user submits the search form the text contents are
applied to the where clause and the list is regenerated.
I found that by adding additional input fields (selects) to the Search
form template, that these additional field values were being appended
to the where clause AND nicely propagated to all of the other actions
on the scaffold (like column sort and pagination).
But there was one glitch. When I added the ":include_blank => true" to
my selects I found that the auto-appended where criteria now included
"where city_id = NULL" which obviously makes my select return 0 rows.
Here's an example of the _search.rhtml template with my mods
