-
Notifications
You must be signed in to change notification settings - Fork 95
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
validations need access to transition information #12
Comments
Have you tried to use "state_machine" gem? It already works as you described, maybe you should consider using it. |
Thanks very much for replying. For some reason I thought this was for Rails 3 (and state_machine wouldn't work), but I don't see that mentioned anywhere, so I just made it up. What's the value of having this gem around? I think you should mention any advantages it has over state_machine, and if there aren't any, mention state_machine, because that's what most people should be using. |
I think the main advantage is the simplicity of the gem. It's much smaller than the state_machine, but has lower functionality. At the beginning state_machine was broken on Rails 3 - that's why I extracted the code of AM::SM, but now I mostly use state_machine gem. |
Ok, that makes perfect sense. Again, I think you might want to mention that on the home page so others don't make the same "mistake" I made. Thanks! |
I have a state transition that sets an association in the model using :on_transition when going from state a to b. I have a validation that fails when the association is set and the state is still a. The problem is that when the validation is called during the state change, it should be valid, but because the state change hasn't happened (state attribute hasn't changed) the validation fails. Seems like the state machine should update the state attribute, THEN run validations, and finally, write the object. Why isn't this the case? In other words, the validations should have a way to know that a state change is occurring, and what the initial and target states are, just like the "dirty" functionality in ActiveRecord.
The text was updated successfully, but these errors were encountered: