On 12 July 2011 19:13, Leigh Daniels <[email protected]> wrote: > Hi Colin, Sayuj and Michael, > > This is a proprietary, in-house app in Rails 3.1rc4 for the U.S market and > they hate date_select ("Date is a little hard to fill out. It is > time-consuming to click on "January" and scroll to "June", etc. Any chance I > could type in 6/3/11?"). > >>If you want to allow the user to enter dates like this you will have >>to parse it yourself to make sure the month and day are as you want >>them. If the site is for an international audience I suggest you use >>separate fields for the three components as otherwise you will have no >>end of trouble as most of the world uses day/month/year. I don't >>understand what you mean by "it happens before the column is available >>in the controller". The field will be passed as a string from the >>form to the controller and should appear in params exactly as entered >>by the user. Note also that, since you have specified a date field in >>the database, what is stored there is not "2011-07-11" or any other >>string, but is the date itself. > > Colin, you are right that params[:start_date] is exactly as entered in the > form. > > What I ended up doing was handling it in the controller with: > [JobsController] > def create > @job = Job.new(params[:job]) > @job.start_date = parse_free_date(params[:job][:start_date])
Something like Date.strptime( params[:job][:start_date], "%Y/%m/%d" ) [ untested ] should do what you want. Don't forget to catch the exception in the case of a parse error. Colin -- 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 [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-talk?hl=en.
