As @mixonic said the states manager has been moved to an external project. The ember router is for all intents a state machine that governs the states you are in as you move through an ember app.
If you have a specific need to build your own custom state machine just download and use the project source and include it in your project after ember.js include. Ember heavily encourages using the router to manage the state of your application. But if you have a use case where you want to have an embedded state machine and don’t want to use the router itself, that is certainly possible. But you will have to bootstrap and define all the states and transitions yourself.
If you read the source code there is relatively up to date documentation and some code examples embedded in the source. I know because I helped reviewed that as part of the documentation edit back in August.
If you have specific questions let me know, I might be able to help with a JSBin example. Have to first understand the specific case though.
Think of the statemanger as the thing that orchestrates the states and implements the logic that allows one state to transition to another. States themselves are just simple objects that are created and you move from state to state.
Here is a generic example of a StateManager from the docs in the source. There is a lot more like this in the source. Definitely look at the source for more. There is a lot of good info there. And the source is not that large so it possible to sit down and understand most of it fairly quickly. Actually the state and state manager are quite beautiful pieces of code. Fairly elegant in their design.
var robotManager = Ember.StateManager.create({
initialState: 'poweredDown',
poweredDown: Ember.State.create({
exit: function(stateManager) {
console.log("exiting the poweredDown state")
}
}),
poweredUp: Ember.State.create({
enter: function(stateManager) {
console.log("entering the poweredUp state. Destroy all humans.")
}
})
});
robotManager.get('currentState.name'); // 'poweredDown'
robotManager.transitionTo('poweredUp');
// will log
// 'exiting the poweredDown state'
// 'entering the poweredUp state. Destroy all humans.'
robotManager.transitionTo('poweredUp'); // no logging, no state change
robotManager.transitionTo('someUnknownState'); // silently fails
robotManager.get('currentState.name'); // 'poweredUp'
here is an even more simplified example that models the states that a door can be in.
doorStateManager = Ember.StateManager.create({
locked: Ember.State.create(),
closed: Ember.State.create(),
unlocked: Ember.State.create(),
open: Ember.State.create()
});
It is up to you to determine the allowable transitions, for example a locked door cannot be open. And a open door cannot be locked. etc…
It is definitely useful to think of a state machine in the abstract in terms of transitions and allowed and disallowed movements between states.
Hope that helps.