Mediators talking to each other about their states

[jaxim]

What's the best practice for one mediator to know about the state of another Mediator's view component.

Reading thru the forum thread, it would seem that I would need to send out a notification to request a value of a state of a view component, at which point another mediator would get the request and send a notification itself with the state value, and then finally the original mediator would get the desired value. But this seems like a round about away of getting a value. Plus, if I need to know the state of 2 or more different view components, then this process seems even more complicated that it really needs to be.

So would it be okay for the mediator to directly call a getter method of another mediator to get the value of the view component state - similar to how a mediator can directly communicate a proxy.

Or is there a better more centralized way of getting the states of the various view components? For example, perhaps a central class listens to the various state notifications from the view and keeps a record of these state changes. So when a mediator needs to know the state of a view component immediately, then it could call a getter method of this centralized class to get the value of the view component state.

Or is there some design pattern that I could utilize to achieve this?

thoughts?

[puremvc]

Lets drop back a step. Why does one mediator need to know the state of another mediator's view component? Give me a valid scenario.

-=Cliff>

[jaxim]

Thanks, Cliff.
Here is an example...

Let's say I need to display a button when a certain notification is sent. However there are certain conditions in which this button should not be displayed even if the notification is sent. Perhaps this button should never be displayed when the application is in full screen or when a global alert window is displayed, or when a various other conditions are present.

It doesn't make sense that every single mediator, which is interested in knowing when an alert window is open, to ALL listen to when a notification is sent notifying that an alert window is opened/closed and that these mediators should ALL keep a boolean value of this condition. The code would be too repetitive otherwise.

It makes much more sense that only the mediator that controls the alert window display object should keep a record of this boolean value. And therefore, all the other mediators should ask this single mediator when they want to know if the alert window is currently open or closed. Same holds true for any other conditions like full screen, etc.

I can understand the logic that you want the view components to be self contained, object-oriented and reusable, but the mediators seem to be the gatekeepers of the view components and the rest of the application. Because Mediators are allowed to communicate to app-specific proxies, mediators seem to be specifically written for a particular application so it would make sense that they are allowed to talk to fellow mediators to get immediate status of other mediators.

What do you think?

[puremvc]

The short answer is: Use the State Machine Utility.
http://puremvc.tv/#P003/

The more detailed answer is:
Don't build amorphous ad-hoc application states by have objects trying to know about the states of other objects and trying to adjust accordingly. Instead, have a central state management mechanism that defines discrete application states, controls transitions between them and broadcasts information about the entering, exiting and establishment of states. When news of a state change comes, you can have different parts of the view organize themselves accordingly.

-=Cliff>

[jaxim]

Does the State Machine Utility replace much of the need of mediators to listen for notifications from proxies so mediators only need to listen to notifications or public method calls from the State Machine Utility?

[puremvc]

The state machine is communicated with via notifications in and out of it. It's just that you're able to cordon off the activity that happens in any given state. Mediators will still listen for notes from proxies, but if you define your state machine as the first part of your app design you'll find that it logically proceeds that the wrong kinds of notes aren't ever issued for the current state to begin with.

For instance, think about being in school. When a period starts, students are in class rooms at their desks not in the halls. Lockers aren't being opened and closed, and food fights aren't breaking out in the lunchroom. Instead books are being opened and closed, tests are being given, etc. Between periods, completely different activities are taking place. What happens at any given time is based upon a running state, operated by a bell that signifies beginning and end of periods or breaks. All the actors in the system (teachers, lunchroom ladies, principals and students) all follow the bell and act according to the current state. This is a 'running status' setup that does not require individuals to 'store' the current state or query it. Teachers don't go to the board and write 'class in-sesssion' or 'between periods' on their blackboards everytime the bell rings, they merely modify their behavior when the bell rings.

Such is the case with the actors in your system responding to the announcements of the state machine.

-=Cliff>

[jaxim]

I am unsure how the state machine utlility (http://puremvc.org/content/view/104/1/) would let all the actors know of the granularity of the state.

For example, let's say I create a mp3 player. A few of the global states can be PLAYING, STOPPED, PAUSED. Now let's say there is a information menu button which when clicked, it shows info about the current playing song and artist. This button does not affect the global playing states of the song; the info screen is opened but the song is still playing. So in this case, is the state still "PLAYING" or is there a new state: "PLAYING, INFO SCREEN OPENED"? Can the state be even more granular: for example what if the application needs to know the full screen status too? Would the State be "PLAYING, INFO SCREEN OPENED, IN FULL SCREEN"?

And to use your school example. The bell notifies everyone that the school state has changed: the period has started/ended. However, when a student goes to gym class and is told that he will be going outside, he checks the weather to see if he should change into shorts or something warmer. The student doesn't wait for a notification from the weather. Instead he looks outside the window and basically asks the weather if it is hot or cold. This may not be the best of examples, but it illustrates my point. There are global states but the actors still may act differently based on the environment or what other actors are doing. And it would seem the best way for the actors in an app to behave is to directly ask the other actors what they are doing and act accordingly.


I'll continue to look into the State Machine Utility to see how the state machine utility can handle this scenario.

thanks.

[puremvc]

The answer is that you combine view states with application states. PLAYING, FULLSCREEN would essentially be a combination of an application state PLAYING and a view state FULLSCREEN. The view component is in charge of maintaining its own state and its behavior in any given state. Flex states is quite helpful with this, but it can be handled with a few more hoops manually in Flash.

-=Cliff>

[jaxim]

thanks, Cliff, for the discussion. It has been very insightful.
:-)

[sideDoor]

The answer is that you combine view states with application states.

This is decent advice for application structure, I find...

Any View complex enough to warrant using the State Pattern should dispatch its own Events based on your needs (StateEvent.TRANSITION_STARTED, StateEvent.TRANSITION_COMPLETE, etc).  This View's State should be accessible and known to any interested Controllers, which is why a public API is defined on the State Machine.  If you're plugging this View into the pureMVC framework, the Mediator stewarding the View could dispatch related pureMVC notifications for any interested pureMVC actors, as needed, as well as broadcast the View's current state to any actor that inquires.

A central State Machine for your overall application is great organization also, but regionally, complex objects should manage their own States.

Just to be clear, in the State Pattern, the term State Machine is given to the object that owns the States, and as so "defines the interface of interest to clients".  So in the case of a View that has States, the View itself IS a State Machine.

[puremvc]

Just to be clear, in the State Pattern, the term State Machine is given to the object that owns the States, and as so "defines the interface of interest to clients".  So in the case of a View that has States, the View itself IS a State Machine.

Actually, the classic State pattern from GoF Design Patterns book isn't related to Finite State Machine implementations at all, but rather defines how an object can behave differently in different states. It describes a class that has a handle method that behaves differently based on what it's internal notion of its state is.

But FSM theory talks about discrete states, transitions between them and controlling those transitions.

FSM is very similar territory to GoF State, but the latter is much more like what I mean by View States, and the former is more like Application States.

-=Cliff>