Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow canceling state transitions #745

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

Allow canceling state transitions #745

lancejpollard opened this issue Apr 26, 2012 · 11 comments

Comments

@lancejpollard
Copy link

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.

@brundage
Copy link
Contributor

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.

@wagenet
Copy link
Member

wagenet commented Jun 17, 2012

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

@tomdale
Copy link
Member

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 as completed Jun 17, 2012
@brundage
Copy link
Contributor

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?

@tomdale
Copy link
Member

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/.

@brundage
Copy link
Contributor

Thanks @tomdale.

@ftokarev
Copy link

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

@tomdale
Copy link
Member

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.

@ftokarev
Copy link

@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

@tomdale
Copy link
Member

tomdale commented Jun 18, 2012

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

@ftokarev
Copy link

@tomdale No

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants