My first state machine - Can it be improved?

63 views
Skip to first unread message

frodefi

unread,
Feb 11, 2012, 10:00:02 AM2/11/12
to PluginAWeek: Talk
Hi all!

I am a newbie to both Rails and state_machine. I was hoping on some
feedback on my state machine definition. It is a simple one, but with
a few states.

To shortly describe what it is for: A project (a doc really) is
created by the user. Admin approves it. Somebody else gives feedback
on the project (and at that time, when first feedback is given, then
the user cannot edit the project any more, if he needs to edit anyway,
he would need to create a new version of the project).

Can my definition be improved?

And in addition: Should I put code that is related to the transitions
here or somewhere else (like, there is an email notification triggered
in one transition, does that code belong in the state machine
definition)?

state_machine :state, :initial => :started do

# A summery of the states:
# :started # initial state
# :entitled # a title is given (and admin will get a email
notification on work in progress)
# :ready_to_publish # The user sets this state. The project is ready
to be published and the user can no longer edit it without going back
an earlier state
# :published # Admin sets this state. The project is fully published,
requires that the user has published first
# :locked # A state where the project is fully published and the user
can no longer go back to an earlier stat to edit the Project. This
happens when first feedback has been given. If the user wants to edit,
he would need to create a new version of this Project
# :new_version_exists # A user has created a new version of this
project (to be able to edit a previous locked version), this project
does not any longer appear in any project-lists, except as an older-
version-link in the new version
# :terminated # A state where the Project is no longer published nor
editable, but the user can make a new version of it and change the
state on this version to "new_version_exists".

event :entitle do
transition :started => :entitled
end

event :set_ready_to_publish do
transition :entitled => :ready_to_publish
end

event :lock do
transition :published => :locked
end

event :make_new_version do
transition [:locked, :terminated] => :new_version_exists
end

event :terminate do
transition all - :new_version_exists => :terminated
end

end

Thanks for any help :)

Frode

Aaron Pfeifer

unread,
Feb 11, 2012, 4:26:18 PM2/11/12
to pluginaw...@googlegroups.com
Hey Frode -

Thanks for posting.  Always happy to provide feedback when possible.  I won't speak for the domain-specific usage of state_machine here, but your definition seems to make complete sense to me.  You've defined a very straightforward machine that's fairly easy to understand.  Nice work.

So far as transition callbacks, like sending e-mails, I personally tend to do a mixture of both in-class callbacks and observer callbacks.  For example, things like sending e-mails I tend to define in observer transition callbacks.  Other things like setting other attributes on the instance as a result of a transition I tend to define in in-class callbacks.  I think you make the call on a case-by-case basis.  You can set a guideline like -- anything that doesn't affect the record itself should be performed in an observer.

Hope this helps and happy state machining!

-Aaron

frodefi

unread,
Feb 24, 2012, 6:56:11 PM2/24/12
to PluginAWeek: Talk
Thanks a lot Aaron for your input :)
Reply all
Reply to author
Forward
0 new messages