Robotlegs Sequencer Actor

AbstractSequencer.as

package com.visfleet.robotlegs.bootstrap {
	import org.robotlegs.core.ICommandMap;
	import org.robotlegs.core.IReflector;
	import org.robotlegs.mvcs.Actor;

	public class AbstractSequencer extends Actor {
		private var steps:Array = new Array();

		[Inject]
		public var reflector:IReflector;

		[Inject]
		public var commandMap:ICommandMap;


		[PostConstruct]
		public function postConstruct():void {
			configure();
		}

		virtual protected function configure():void {
			throw new Error("Override " + reflector.getFQCN(this) + "#configure and don't call super", 8725414);
		}

		protected function addStep(commandClass:Class):void {
			var classFQN:String = reflector.getFQCN(commandClass);

			steps.push(classFQN);

			commandMap.mapEvent(classFQN,commandClass,SequenceStepEvent,true);
		}
		
		public function step():void {
			if (!stepsRemain())
				return;
			
			executeNextStep();
		}
		
		private function executeNextStep():void {
			var classFQN:String = steps.shift();
			var event:SequenceStepEvent = new SequenceStepEvent(classFQN, this);
			
			dispatch(event);
		}

		public function stepsRemain():Boolean {
			return steps.length > 0;
		}
	}
}

SequenceStepEvent.as

package com.visfleet.robotlegs.bootstrap {
	import flash.events.Event;

	public class SequenceStepEvent extends Event {

		public function SequenceStepEvent(classFQN:String, sequencer:AbstractSequencer) {
			super(classFQN);
			this.sequencer = sequencer;
		}

		private var sequencer:AbstractSequencer;

		public function step():void {
			sequencer.step();
		}
	}
}

ZZSampleCommand.as

public class ConfigureScheduleHeaderViewCommand extends Command {

    [Inject]
    public var event:SequenceStepEvent;

    override public function execute():void {
        mediatorMap.mapView(TimelineView, TimelineMediator);

        event.step();
    }

}

Thanks for the explanation.

I guess the first part could also be solved by directly injecting the sequencer itself and letting the command invoke executeNextStep on it. But I definitely agree about the second argument: Having the ability to get an overview of the mapped commands is very helpful indeed. Also, performance really shouldn't be a concern at this level anyway, so the slight overhead probably isn't an issue, either.

God no, performance did not get a look in. I can bootstrap with hundreds of sequence events (across modules) and not even notice it.

That's what I thought. Thank god the bad old days of the AVM1 are over.

And now I'm back to optimizing the performance of SwiftSuspenders ;)