Don't use the MacroCommand if you want async breaks between the subcommands. The AsyncCommand utility was meant to do this, and some folks use it and report good things with it.
But the approach I advocate is to use the StateMachine Utility to define discrete application states and control the transitions between them.
How does it do this? Well, basically it becomes like the conductor of your orchestra. Commands and Mediators mostly just listen to it, not each other. It is in charge of knowing the current state and what actions can trigger transitions to other states.
So in your example, lets say you're in state FOOING, leaving it you want to do a transition and we'll call that state BARING and then your next state is BAZING, during which you want some more logic to execute.
And...
click a button in one view that sends a notification to a macro command via that view's mediator
Actually, you send a StateMachine.ACTION notification (like DONE_FOOING) (and perhaps carrying a value object representing a form submission) via that view's mediator. This triggers a change to into state BARING, when the StateMachine will send out a custom announcement notification about the specific state change that you can listen for.
Now, have your Mediators listen for this state change and do their view manipulations, and:
[have] one view in particular to commence a simple tween.
During this tween, nothing else is happening because there's no pending logic (subcommands) to execute. The StateMachine is just waiting to hear an action to trigger a state change.
once that simple tween is complete, I want the execution of the rest of the subcommands to commence again.
You send another StateMachine.ACTION notification via the view that was tweening's Mediator (DONE_BARING). The StateMachine knows that this a valid action to transition into the next state BAZING. The rest of the logic that you were going to have run after the async break could be a MacroCommand that listens for the change into state BAZING.
Hope this helps.
-=Cliff>
