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

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

On Feb 11, 10:26 pm, Aaron Pfeifer <aaron.pfei...@gmail.com> wrote: