excid3 / combined_time_select

A Rails time_select like Google Calendar with combined hour and minute time_select

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

failed validations

edatrix opened this issue · comments

hello again.

because the parse_time_select! is called upon create, it's pushing the parsed time in as the value for :start_time (or whatever the field is called) and, therefore, bypassing validations. now, even if no time is selected, when the form is submitted the error is not raised because parse_time_select! puts something in there.

i've tried to set a default value as nil and to add conditions so that parse_time_select! occurs after the form is successfully saved, but no luck.

how can i use this and still validate presence of these fields?

(i'm happy to do the work myself and submit pull requests, but couldn't figure this one out...)

thanks!

I've run into this problem as well. It's surprisingly tricky.

This obviously needs some refactoring inside the gem, but my temporary suggestion would be to add an if statement to the parse line in the controller for now.

  params[:event].parse_time_select! :start_time if params[:event]["start_time(5i)"]

Basically check to see if one of the time paramters was sent over. This gem needs more of an overhaul and a better way to handle these seamlessly. I'm not sure what the best solution is yet, but let me know if this solves it for now.

Thanks for your help Chris!

my temporary suggestion would be to add an if statement to the parse line in the controller for now

I've just experimented with that ... when the rails "multiparameter attribute" param is incomplete, say, this being the totality of it:

"available_at(5i)"=>"00:00:00"

... it makes Rails unhappy. I'm currently getting a gloriously vague undefined method 'empty?' for nil:NilClass ... yesterday when experimenting, I was getting error(s) on assignment of multiparameter attributes.

I think Rails is not natively set up for dealing with incomplete multiparameter attributes. From researching a little, it seems one way to deal with it, would be to override the datetime setter method in the the model, and add various validation errors there (write your own version of parse_time_select, basically).

Another way, referenced in this SO question, would be to split the DateTime into two attributes, one for date, and one for time, and write out all the parsing by hand. This would be more verbose, but also fairly easy to understand, and flexible.

That makes sense that Rails freaks out about the multiparameter attributes being incomplete. That multiparameter should get deleted and should replace the :start_time with an actual Time object and shouldn't make it though to the model.

Either way, this definitely isn't a great solution for the problem. I wonder if using Chronic would save us a lot of time. We could just send over "11:30 AM" as a string and use Chronic to convert it potentially. Thoughts on using it as a dependency?