application flow with 4 phases

[nrocco]

Hi, currently i'm working on a project which has the following flow:
# phase 1 : user sees a video playing that loops infinite till user clicks somewhere
# phase 2 : user is guided through a form where he has two fill in some details, in the end, he clicks on a button GO
# phase 3 : user sees some kind of video based on variables he filled in, in phase 2. user can watch video again and again or go to phase 4
# phase 4 : user sees some kind of view with thank you etc etc... not important.

How would i organize this architecture? In my opinion:

application starts
-> StartUpCommand called (does something (creating StageMediator etc))
-> PreparePhase1Command is called (does something)
-> command fires INITIALIZE_PHASE_1 notification
-> StageMediator listens to this and creates mediator for phase1 which then puts all the views needed in phase one on stage
-> after clicking somewhere on stage the notification PREPARE_FASE_2 is fired
-> notification picked up by PrepareFase2Command.... (does things...) and fires INITIALIZE_PHASE_2 notification
-> this notification is picked up by the StageMediator to remove phase1 view stuff away from the stage and will put all things needed for phase 2 on stage
.... and so on for phase 3 and 4....

First of all:
# I'm not sure if this is a best practice or in anyway a reasonable approach to my 'problem'.
Also:
# When i enter phase 2, where do i leave my phase 1 view stuff and so on for phase 2,3 and 4....
Finally:
# Should I implement MacroCommands and if so, where?

I'm building my application using the Flash CS3 IDE together with Eclipse and FDT 3.0 (but this shouldn't matter for the application structure).
I am experienced in using AS 2.0 and ARP, and i'm working with PureMVC and AS 3.0 for three weeks now.

Hoping for some beautiful insights... Ciao

[puremvc]

Sounds like a reasonable approach. However, you may find that you don't need the commands so much, as you can have multiple mediators respond and set their state, retrieving model elements as needed and setting them into the view.

This cuts down on the number of Notifications being sent, the number of classes that need to be written (less commands), and lets the view sort of be 'self-organizing' since each facet that needs to change with any given Notification can do so easily without much work. Any data massaging ought to happen in the model, so that mediators aren't doing much work to get the data and poke it into the view or vise versa.

-=Cliff>