Usage of new Finite State Machine? how to?

Hello All,

i’ve read and reread the new FSM explanation in the manual and also the music box tutorial but i’m still lost …

My need is the following:
my entity have this life cycle:
Creation (internal setup from disk saved data and configuration file)
Spawn (link with other entities already created)
Published (entity if needed is published as a distributed object)
Enable (the entity is ready to perform one shot action or it starts background
permanent action)
Activate (entity do the one action).
and their opposite State (Unactivate, Disabled etc…).

Currently this is implemented via a mix of if/then and message.

Is it a good situation to make a FSM?
Can a new FSM permit this:
between “spawn” and “enabled” or between “enable” and “activate”, one or more event allow the transition depending of the entity config file

How in a new FSM, i decide the name of the state ? i define the allowed transition and the forbidden one? i request an allowed transition from a message?

Also , is it possible in a new FSM to have properties and event accepted by all states without having to rewrite the accept code in each state?

When using an FSM, you have to make sure that each state at no time is designed to intersect with another. This is because you can’t be in two states at the same time. If for example, you need to be Published and Enabled at the same time, an FSM would be a bad choice fo those two two states.
You say you have statements of if/then. You need to make sure they are more like elif/then.

The name of a state in the new FSM style is any string, with the initial letter capitalized. You define each state by creating the enter, filter, and exit functions for it. For example if I name a state 'MyState" I would have:

enterMyState()
filterMyState()
exitMyState()

as defined methods inside of my FSM.

You can redefine the defaultFilter for any general case that you want. This is the easiest way to have requests that all states should handle. The original default filter for the new FSM is to allow any requests that begin with a capital letter. So self.request(“MyState”) would always create a successful transition, while self.request(“myState”) would not (when using the default filter).

To define allowed transitions from a specific state, you would define the states filter function, which would override the defaultFilter:

def filterMyState(self, request, args):
    if request == "anotherState"
        return (request,) + args
    elif request == "new":
        return("UnholyState",)+args
    else:
        return self.defaultFilter(request, args)

Note that you dont need to directly request the states name, you can return any state based on the request string.

To request a state from an event message is easy. FSM inherits from DirectObject, so all you have to do is say something like:

self.accept(‘Jersey’, self.request, [“new”]).

You can do this in init or in the enter/exit functions of a state.