In my current side-project I'm playing with using
acts_as_state_machine to implement some of my model behaviour.
Now, it has occurred to me that using this pattern is in some way in
conflict with the way that things are normally done in rails.
For example, I find my guard functions (for the state transitions) are
duplicating validations on my model.
A specific example of this is a User model. It validates_presence_of,
validates_confirmation_of and validates_length :password.
Additionally, the transition from verified to active has a guard
function which makes sure that the password is valid.
This duplication seems necessary in part because the state transitions
use update_attribute to change state (thereby bypassing
validations)... so, the guard function has to worry about things.
Unfortunately, this also means that firing an event/transition can
commit a model in an invalid state. I can add valid? to the guard, but
then all the guard function can do is prevent the transition... not
report any errors...
At this point I start to think that there's a general flaw in either
the implementation, or in my usage of the plugin.
It also seems to me that I should be able to set the state manually in
an model while I'm changing other attributes. Then, when I save, a
series of callbacks could detect the implied transition and guard if
necessary (inline with the other validations?), plus implement with
the various enter and exit state callbacks.
So, what I'm wondering here on core is... is there a more rails-like
way to do these sorts of things? It seems that using observers to
"notice" state changes is the more rails-like way... but then you
don't get the extra event transition methods, state testing methods,
Is this something that a new, more rails-like "state_machine_fu"
plugin should implement... with the possibility of merging into core
later? Does anyone have any suggestions for what the "more rails-like"
way would be? General thoughts?