Comments on: acts_as_state_machine and variable initial states http://www.rubyfleebie.com/acts_as_state_machine-and-variable-initial-states/ Because programming should be fun Fri, 12 Mar 2010 13:31:44 +0000 http://wordpress.org/?v=2.1.2 By: macournoyer http://www.rubyfleebie.com/acts_as_state_machine-and-variable-initial-states/#comment-669 macournoyer Wed, 10 Sep 2008 18:58:51 +0000 http://www.rubyfleebie.com/acts_as_state_machine-and-variable-initial-states/#comment-669 Hey Frank, I think the best way is: def create user = User.new(params[:user]) user.enable! end enable! calls save, no hacks and pretty explicit. Changing a class attribute like this is not good practice and would prevent your app from being multi-thread amongst other things. Hey Frank,

I think the best way is:

def create
user = User.new(params[:user])
user.enable!
end

enable! calls save, no hacks and pretty explicit.
Changing a class attribute like this is not good practice and would prevent your app from being multi-thread amongst other things.

]]> By: Frank http://www.rubyfleebie.com/acts_as_state_machine-and-variable-initial-states/#comment-670 Frank Wed, 10 Sep 2008 19:00:55 +0000 http://www.rubyfleebie.com/acts_as_state_machine-and-variable-initial-states/#comment-670 Marc, thanks for your input. Feel a bit silly now ;) However I still wonder why it isn't possible to bypass the initial state specified in the model. I'd prefer if I could just send the "state" attribute among the rest like that : User.new(:name => "blabla", :state => "enabled") Marc, thanks for your input. Feel a bit silly now ;)
However I still wonder why it isn’t possible to bypass the initial state specified in the model. I’d prefer if I could just send the "state" attribute among the rest like that : User.new(:name => "blabla", :state => "enabled")

]]> By: Frank http://www.rubyfleebie.com/acts_as_state_machine-and-variable-initial-states/#comment-671 Frank Wed, 10 Sep 2008 19:43:00 +0000 http://www.rubyfleebie.com/acts_as_state_machine-and-variable-initial-states/#comment-671 Hmm... interesting. I started experiencing some weird deadlock errors as soon as I tried what you said Marc. I am too lazy to check the plugin code but I would guess it does something special with the "!" events. Or maybe it's something completely unrelated... still checking the issue. Hmm… interesting. I started experiencing some weird deadlock errors as soon as I tried what you said Marc. I am too lazy to check the plugin code but I would guess it does something special with the “!” events. Or maybe it’s something completely unrelated… still checking the issue.

]]> By: Cyberfox http://www.rubyfleebie.com/acts_as_state_machine-and-variable-initial-states/#comment-673 Cyberfox Thu, 11 Sep 2008 01:12:02 +0000 http://www.rubyfleebie.com/acts_as_state_machine-and-variable-initial-states/#comment-673 Greetings, I believe the reason you can't do that is that you'd be jumping to a middle state of a state machine. Essentially you'd be bypassing any code that was set up to happen during transitions. The system needs to trigger when you transition from (for example) :free to :paid, so it can provision you with the appropriate features. In order to trigger on transition between states, you have to have a consistent starting state. Think of it as stateful integrity, a term that has only two Google hits, so I consider myself to have made it up just now, for just this purpose. :) -- Morgan Greetings,
I believe the reason you can’t do that is that you’d be jumping to a middle state of a state machine. Essentially you’d be bypassing any code that was set up to happen during transitions.

The system needs to trigger when you transition from (for example) :free to :paid, so it can provision you with the appropriate features.

In order to trigger on transition between states, you have to have a consistent starting state.

Think of it as stateful integrity, a term that has only two Google hits, so I consider myself to have made it up just now, for just this purpose. :)

– Morgan

]]> By: Frank http://www.rubyfleebie.com/acts_as_state_machine-and-variable-initial-states/#comment-674 Frank Thu, 11 Sep 2008 12:48:41 +0000 http://www.rubyfleebie.com/acts_as_state_machine-and-variable-initial-states/#comment-674 Cyberfox, good call, it makes sense. So basically I should redesign my "user state machine" to have just 1 initial state. Maybe have the following states : All new users could be : new (initial) Unapproved users : unapproved Enabled users : enabled Disabled users : disabled And the events : approve! (from :unapproved to :enabled) enable! (from :new to :enabled) disable! (from :enabled to :disabled and from :unapproved to :disabled) I guess that would be better than having more than 1 initial states. Any thoughts? Cyberfox,

good call, it makes sense. So basically I should redesign my “user state machine” to have just 1 initial state.

Maybe have the following states :

All new users could be : new (initial)
Unapproved users : unapproved
Enabled users : enabled
Disabled users : disabled

And the events :
approve! (from :unapproved to :enabled)
enable! (from :new to :enabled)
disable! (from :enabled to :disabled and from :unapproved to :disabled)

I guess that would be better than having more than 1 initial states. Any thoughts?

]]> By: pravs http://www.rubyfleebie.com/acts_as_state_machine-and-variable-initial-states/#comment-848 pravs Tue, 30 Jun 2009 14:33:56 +0000 http://www.rubyfleebie.com/acts_as_state_machine-and-variable-initial-states/#comment-848 Hello Frank, I am bit confused Isn't it good way to use "User.write_inheritable_attribute :initial_state, :enabled" Because I want to assign the specific state (e.g. :xyz) initially only in few cases. And in other cases when i migrate from any other state to :xyz and have to perform some events which are not required in first case. Therefore I cannot use User.xyz! as this performs all the event actions when I do this. So can anyone suggest me a good way to do this. "User.write_inheritable_attribute :initial_state, :xyz" serves my purpose but as someone has already said its not a good practice. Hello Frank,
I am bit confused
Isn’t it good way to use
“User.write_inheritable_attribute :initial_state, :enabled”
Because I want to assign the specific state (e.g. :xyz) initially only in few cases. And in other cases when i migrate from any other state to :xyz and have to perform some events which are not required in first case.
Therefore I cannot use
User.xyz! as this performs all the event actions when I do this.

So can anyone suggest me a good way to do this.
“User.write_inheritable_attribute :initial_state, :xyz” serves my purpose but as someone has already said its not a good practice.

]]>