Triggering the removal of a core

[serka]

I'm having some trouble finding the right way to remove a core in my application. It seems that I am removing a core "too early". Here is a simplification of my app design.

• Shell S has a state machine, with a linear set of transitions, A > B > C > D
• S instantiates module M when it sees a state-specific changed notification from B
• M has its own state machine, with a linear set of transitions, E > F
• Some time later, M dispatches an Event.COMPLETE when it reaches the end state, F (internally triggered by a state-specific changed notification from F)
• A Mediator for M in S listens for Event.COMPLETE and sends a StateMachine.ACTION that should transition S's state machine from B to C
• A Command registered to F's state-specific changed notification removes M's core.

This appears to be too early because once Facade.removeCore(M.NAME) completes, the long stack of notifications begins to end and eventually after M's state machine sends the state-specific notification for B, it attempts to send a StateMachine.CHANGED notification. Sending the notification triggers a new Facade instance with M's multiton key to be created. I'm left with M having been removed, but an "imposter".

In my first stab to fix this, I changed the dispatching of Event.COMPLETE in M to trigger off of StateMachine.CHANGED, but I ran into a similar problem because another mediator in M is also interested in StateMachine.CHANGED, but its observer comes after.

For now, I perform the clean up in a command triggered by changing to D, but this feels wrong. It looks like I've done something fundamentally wrong with my usage of multicore and statemachines.

The Question:
How do I ensure M is done using the facade, or otherwise does not attempt to use its facade after I call removeCore()?

On a loosely related note, what's a best practice in having M communicate to the outside world? Dispatching an event based on the state-specific changed notification leaves the state machine blocked in the middle of transitionTo() and that doesn't seem quite right.

[puremvc]

A Command registered to F's state-specific changed notification removes M's core.

Don't try to remove a core from within that core. You're having Module M try to remove its own core. Instead, have the mediator for M in S remove the core when it hears from M that it is moved to its F state.

-=Cliff>

[serka]

::facepalm::

Sorry, I meant to say "A command (in S) registered to C's state-specific changed notification..."

[puremvc]

sounds like the notification storm needs to die down before you do the removeCore. You have two state machines transitioning in the shell's and in the module. So, you need to be sure the module's state machine reaches a quiescent state before removing the core.

Some time later, M dispatches an Event.COMPLETE when it reaches the end state, F (internally triggered by a state-specific changed notification from F)

Instead, try sending this event when the StateMachine.CHANGED happens in M (an the new State is F).

-=Cliff>

[serka]

Thanks Cliff.

Looks like I'll have to take a look at the module and see how I can ensure everything has quieted down. Perhaps a new final state where I make sure only one thing reacts to the final StateMachine.CHANGED.

What is your opinion on using setTimeout with a delay of 1 to trigger the event (which eventually triggers the shell's state transition)? It doesn't feel proper, but it does seem to have the effect of waiting for the notification storm to end before.

[puremvc]

Well, it's a way of going async and letting the call stack collapse, but I don't like it. It's sort of like the old Draperism "IF 2+2=5 THEN LET 2+2=4" if you catch my drift.

I believe that responding to StateMachine.CHANGED on whatever the final state of the module is would be best. I don't know that you need a specific final