Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

failed validations #9

Open
edatrix opened this issue Nov 14, 2014 · 4 comments
Open

failed validations #9

edatrix opened this issue Nov 14, 2014 · 4 comments

Comments

@edatrix
Copy link
Contributor

edatrix commented Nov 14, 2014

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!

@kevinmtrowbridge
Copy link

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

@excid3
Copy link
Owner

excid3 commented Apr 1, 2015

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.

@kevinmtrowbridge
Copy link

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.

@excid3
Copy link
Owner

excid3 commented Apr 14, 2015

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants