Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Allow canceling state transitions #745

Closed
lancejpollard opened this Issue Apr 26, 2012 · 11 comments

Comments

Projects
None yet
5 participants

Related to the previous issue, it would be very useful to prevent state transitions. Perhaps another flag on the transition object:

stateManager.goToState 'nestedState'

nestedState: Ember.State.create
  enter: (stateManager, transition) ->
    transition.cancel() if x

What do you think?

A use case is, if you have async operations, and somewhere totally unrelated, the code calls goToState, it should prevent the transition until the async operation is complete.

Contributor

brundage commented Jun 15, 2012

I think this feature makes sense. If you keep user authentication status in the state machine it would be great to be able to bounce an unauthenticated user out of the "logged in" state tree. Example: question on stackoverflow and code on jsFiddle.

This raises the question: where do you do after canceling a state transition? Perhaps along with the cancel event you have to provide a destination state.

Owner

wagenet commented Jun 17, 2012

@wycats, @tomdale, what's the current line of thought on this?

Owner

tomdale commented Jun 17, 2012

Nope, this is definitely not allowed under the state chart model. The entire point of states is to avoid situations like this. @viatropos, you should be modeling your async operations as events being sent to the state manager. It is the responsibility of the current state to handle them. This forces you to be more rigorous about modeling the different states you can be in, which is why they are beneficial.

If you'd like to discuss your particular use case more, we can figure out a way to model it in terms of states and events without having to cancel transitions, I'm sure. :D

@tomdale tomdale closed this Jun 17, 2012

Contributor

brundage commented Jun 17, 2012

So, in my situation above (authenticated actions with the state manager), all the logged-in actions should go in the authenticated. That makes sense. What is a good strategy for making sure controls (like links) disappear once the user logs out?

Owner

tomdale commented Jun 17, 2012

@brundage The way I like to model this is to have the state that is responsible for handling those actions also be responsible for showing and removing related views. This is basically the problem that the outlet pattern is designed to handle: http://emberjs.com/guides/outlets/.

Contributor

brundage commented Jun 17, 2012

Thanks @tomdale.

@tomdale, what's wrong with canceling state transitions? AFAIK, David Harel's paper does not explicitly forbid this case.

Owner

tomdale commented Jun 18, 2012

@ftokarev The advantage of state charts is that they help eliminate ambiguity about behavior. Canceling a transition creates ambiguity because it is unclear what the current state should now be. If a state wants to cancel a transition, it should just explicitly transition into a new state; that way it is clear from reading the code exactly what the new state is.

@tomdale,

Canceling a transition creates ambiguity because it is unclear what the current state should now be.

I think the state which cancelled a transition should become the current state

Owner

tomdale commented Jun 18, 2012

@ftokarev Do you have a reference to the concept of cancelation in the literature?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment