Mediators organization

[gkf]

Hello, it's my first message here

I use PureMVC for my Flex application.
The main mxml application file has three panels in.
Each panel is linked to its mediator.
I already manage states in each panel using their mediators.
I wan't to manage states of my application to remove or add those panels.

To be able to do that, I want to add a container (panel for example) at the top level of my application (containing the three panels) with its own mediator.
This mediator will observe notifications to change the state of the application. I think I will have to manage registration of mediators linked to panels added or removed.

Do you think it's a good idea ?

[puremvc]

If you're wanting to define and manage the discrete states of your application, (as opposed to just view states), you probably want to have a look at the StateMachine utility.

http://puremvc.tv/#P003
-=Cliff>

[gkf]

Thanks for your reply.

This StateMachine looks powerfull to manage states of an application. I'm going to try to use it.
Is there any code examples ?
I hope I will be able to manage view states transitions too.

[puremvc]

For a working example of the StateMachine in a real application, you can peruse the original source for the Sea of Arrows site:
http://darkstar.puremvc.org/content_header.html?url=http://seaofarrows.com/srcview&desc=Sea%20of%20Arrows%20Source%20Code

And here is a link to the associated FSM diagram and discussion.
http://puremvc.tv/#P004/T435

-=Cliff>

[gkf]

Thanks for the code example.

I don't really want to manage states of my application with FSM now (maybe later). It has not lot of states.

My problem is to manage view transitions of the application.

If I define states and transitions in my main mxml file, who will manage those view states ? A mediator ?
Those transitions will remove and add panels already managed by their own mediators.
Will I have to remove a mediator if the transition removes its panel ? And create it again when another transition creates the panel ?

[puremvc]

The view components themselves should encapsulate their own states. They should not rely upon mediators or any outside actor in order to transition to or represent its own internal states. Think of it this way; as close a friend as your best friend may be you wouldn't put him or her in charge of your heartbeat or liver function would you?

In MXML it is easy to define view component states and transitions, and this is where they should reside. The mediator will continue to interact with an API you expose to it; setting properties, calling methods, and listening for events. But those methods and properties do not need to expose any information about the internal states of the component.

For instance, you might have a view component that exposes a bindable ArrayCollection of value objects that gets populated by data retrieved from a service. When the data is retrieved, we want the component to display the data in a table. But until the collection is populated you might have the component be in a state that has only a spinner graphic and a 'loading stuff' message. The component starts in this state when it is created.

After some period of time, the entire view hierarchy is built, the PureMVC apparatus attached, and the service call made to get the data that will eventually be passed to this view component on that bindable ArrayCollection. In a bit, the Proxy gets the result, sends a notification which the mediator hears and responds to by plucking the ArrayCollection of value objects from the note and setting it on the public property of the view component.

Inside the view component, the presence of the ArrayCollection can immediately trigger a state transition in a couple of ways. The easiest is to have a binding expression on the component's currentState property that evaluates whether the list is null and returns the appropriate state name.

Or you can do this by having an implicit getter and setter for the collection that sets or returns a private local ArrayCollection variable. In the setter, the currentState is changed to the 'display' state, where the spinner and loading message are gone and in their place is a datagrid whose dataProvider is showing all the value objects in the collection.

The key to all this is that the mediator didn't need to explicitly know or manage the states of the view component. The component encapsulated its own behavior; defaulting and transitioning to the requisite states of its own accord in response to simple data delivery from the mediator.

-=Cliff>

[gkf]

Thank you for your answer.

I have a mediator which manages the currentState of its view. I'm going to change that and make the view manage its view states

My main question still remains .

Imagine my main application mxml file (main.mxml) having two view components panel P1 and panel P2.
Each panel has its own mxml file (in the view/components directory).
P1 has a mediator M1 and P2 has a mediator M2 (each mediator has its own source file in view directory).
I define states and transitions of my application in the main.mxml file.
Suppose, base view state has both panels and another view state S1 has only panel P1.

Changing from base state to S1 will remove child P2.
Do I have to remove M2 before this states transition ?
Do I have to create once again M2 after a transition from S1 to base state ?

[puremvc]

Changing from base state to S1 will remove child P2. Do I have to remove M2 before this states transition ?

No. You can have M2 listen for a 'removed' event from its view component, and respond by simply removing itself. Then in M2's onRemove method, remove all event listeners from its view component and and set the view component to null.

Do I have to create once again M2 after a transition from S1 to base state ?

Yes. You'll probably want the mediator for the main application to listen for 'added' events, which will contain a reference to the added component, and instantiate the appropriate mediator there. That way it doesn't matter if its the first time through or not, the mediator is registered via the same facility each time.

-=Cliff>

[gkf]

Thanks for all your replies