Thanks, Deril and Cliff.

I appreciate you taking the time to entertain my questions and thoughts.
:-)

As I mentioned, please ignore how I implemented pureMVC, but rather concentrate on the logic of the for-loop of the View class. It doesn't make sense that a Notification that was sent after another notification would be received before that previous notification.

If you cannot get pass how I chose to implement pureMVC, then I guess we are at an impasse and I am not sure how to make my point.

Again, thanks for taking the time to review this topic.




p.s. You could still change the logic that I stated to the one you specified and the problem could persist due this for-loop logic. So instead of the mediator checking if its sprite is visible, it checks the proxy's state which you suggested. However, because the "DISPLAY_LOGIN" notification was sent while the "ENTER_PRESSED" was still being sent, that could have changed the state stored in the proxy and so when the for-loop got to the 7th mediator in my example, the Mediator would react to the "ENTER_PRESSED" notification.

But again, please try to concentrate on the for-loop of the View class and see if my suggested "queuing of notifications" code makes sense.

Sorry for not making sense. I should of proofread my last post. Let me try to explain it again.

When a notification is sent out, there is a potential that additional notifications may be sent and received before the 1st notification has completely been received. The 1st notification will eventually be received by all observers, but sometimes other notifications may be sent and received in the middle of sending out the 1st notification.

Your example with the preloader isn't the problem I am seeing. Your example has 12 separate notifications being sent out at separate times. For example, a "loaded" notification that the background image was been loaded, another "loaded" notification that an XML file was loaded, etc. In this use case, there is really only one observer of the "loaded" notifications.

What I am saying is that there are many observers listening to a single instance of a notification. For example, let's say that there are 12 observers listening to hear when the ENTER key is pressed. Each of these 12 observers have a different sprite associated with them. These observers only react to the ENTER key if their sprite is visible. So what here is a potential use case when the ENTER key is pressed.

1) the user presses the ENTER key
2) One class is listening for this event. When it hears this event, it sends out a notification "ENTER_PRESSED"
3) There are 12 mediators listening for this "ENTER_PRESSED" notification
4) The View class tells these observers about this "ENTER_PRESSED" notification by performing a for-loop
5) The 1st 5 observers within this for-loop do not react to the "ENTER_PRESSED" notification because their sprite is not visible.
6) However, the 6th observer does react because its sprite is visible.
7) Upon hearing that the ENTER key has been pressed, the 6th observer sends out a notification requesting a new display to be visible. The name of this notification is called "DISPLAY_LOGIN". This notification is either sent out directly by this 6th observer or by a command - it doesn't matter.
8) The "DISPLAY_LOGIN" notification has a few observers. The View class uses its for-loop to tell this new set of observers of this new notification.
9) One of the observers that is listening for the "DISPLAY_LOGIN" notification reacts and causes its associated sprite to be visible.
10) The "DISPLAY_LOGIN" notification for loop finishes.
11) Now the code continues with the "ENTER_PRESSED" notification for loop that was started from the beginning.
12) The 7th observer is told of the "ENTER_PRESSED" notification, then the 8th, 9th, 10th.
13) The 11th observer so happens to be the same observer that reacted to the "DISPLAY_LOGIN" notification. Because the "DISPLAY_LOGIN" notifcation caused the 11th observer to display its associated sprite, the "ENTER_PRESSED" notification causes the 11th observer to react. The 11th observer send out a "FIELD_COMPLETED" notification, which in turn causes any observers of that notification to react.
14) Eventually the 12th and final observer is notified of the "ENTER_PRESSED" notification.

Do understand why I think this isn't logical? Look at my sample code to see how I rectified the problem. With my modified/extended View class, the use case I laid out above would play out in the following manner:

1) the user presses the ENTER key
2) One class is listening for this event. When it hears this event, it sends out a notification "ENTER_PRESSED"
3) There are 12 mediators listening for this "ENTER_PRESSED" notification
4) The View class tells these observers about this "ENTER_PRESSED" notification by performing a for-loop
5) The 1st 5 observers within this for loop do not react to the "ENTER_PRESSED" notification because their sprite is not visible.
6) However, the 6th observer does react because its sprite is visible.
7) Upon hearing that the ENTER key has been pressed, the 6th observer sends out a notification requesting a new display to be visible. The name of this notification is called "DISPLAY_LOGIN". This notification is either sent out directly by this 6th observer or by a command - it doesn't matter.
8) The extended View class hears about the "DISPLAY_LOGIN" notification, but because the previous for-loop is still in progress, it places the "DISPLAY_LOGIN" notification in a queue.
9) The remain 12 observers are notified of the  "ENTER_PRESSED" notification. None of the remaining observers react because their associated sprites are not visible.
10) The extended View class then starts a new for-loop to tell a new set of observers of the next notification in its queue: the "DISPLAY_LOGIN" notification.
9) One of the observers that is listening for the "DISPLAY_LOGIN" notification reacts and causes its associated sprite to be visible.
10) The "DISPLAY_LOGIN" notification for-loop finishes.
 

With my extended View, the use case doesn't cause one of the observers to improperly react to the ENTER notification. You can argue that I should construct my notifications/mediators differently, but the point is that the framework should be flexible. I still can't see the use case where the programmer would want the 2nd "DISPLAY_LOGIN" notification to be sent and received by a new set of observers before the 1st "ENTER_PRESSED" notification.


Hopefully I explained myself more clearly this time. Please let me know if things are still not clear.

Thanks for chiming in, Cliff.

The thing is that my Mediators are already decoupled from each other. They don't communicate to each other directly but rather use notifications to indicate (for example) when a mediator's sprite has been displayed.

But putting aside how I implement puremvc, my question still stands:
Should observers of the notification system receive notifications that were not before other notifications? To me, this seems like an oversight which may not have been so obvious. But perhaps it was made this way by design. What are the use cases when one would want a later notification to be received by an earlier notification? Or should my code change be considered in a later version of PureMVC? What do ypou think, Cliff.

Much thanks!
Jack

 

Thanks, Deril, for the attention in this matter.

I eventually chose to extend the core View class to get pureMVC to do what I wanted.

Do you see something wrong with wanting that a notification is received by all observers before subsequent notifications are received?

What you suggested, may not have worked for me. Even if I get the command to send the 2nd note, the 2nd note would still get received by some mediators before the 1st note was received. So I chose to extend View so notifications would be placed in a queue and wouldn't be sent out until the preceding notification was done being sent.

The following is an excerpt of the extended View class that I made. Now when I send Note1, it is received by all observers before any other notes are received, even if additional notifications are sent within the notification loop that is sending note1.

:

/** The vector array that contains the list of notifications that should be sent to the application.  **/
private var _vNotifications:Vector.<INotification> = new Vector.<INotification>();

/** The notitfcation that is currently in the process of being sent. **/
private var _noteCurrent:INotification;

/**
* Override notifyObservers() so notifications that are sent to this method are completely sent before a different notfication is sent.
*/
override public function notifyObservers(notification:INotification): void {
if(observerMap[notification.getName()] != null ) {
_vNotifications.push(notification);
if(_noteCurrent != null){
//If there is a previous notification still being sent, then do not proceed to notify the next notifcation
//until the previous notification has completely been sent to all observers.
return;
}
_noteCurrent = notification;
super.notifyObservers(notification);

//once the notification has been sent, remove the notification from _vNotifications
var iLength:int = _vNotifications.length;
for(var i:int = 0; i<=iLength-1 && iLength>0; i++){
if(_vNotifications[i] == notification){
//most likely this will be the 1st item in the Vector Array
_vNotifications.splice(i,1);
break;
}
}
_noteCurrent = null;
//if there are still notifications in _vNotifications, then notify the observers of the next 1st notification within the vector array
if(_vNotifications.length > 0){
notifyObservers(_vNotifications.shift());
}
}
}


Here is what I am doing with my 2 notifications, but keep in mind that there could be other cases like this.

Note1 is dispatched when the user clicks the ENTER key. The mediator then decides how to behave when the enter key is pressed. Sure, I could of made the mediator or its sprite listen directly to a keyboard event, but I wanted to be able to control the turning on and off the listening of the keyboard events centrally so that all of the app is affected and behaves the same way by keyboard events. And I guess I could create a singleton Keyboard class that all of my application's mediators/sprites listen to, but isn't the whole point of PureMVC is that you notify the app using its notification system?

So anyway, The Enter Notification is received by Mediator1, It sends out a notification that something should happen which then triggers a DISPLAY notification to be sent  (or rather a command tells mediator2 to display its sprite)  which causes Mediator2 to display its sprite. The Enter Notification finally reaches Mediator2. Mediator2 is set to only react to the Enter Notification if Mediator2's sprite is visible. Because the DISPLAY notification is received by Mediator2 before the ENTER notification (even though the ENTER notification was sent 1st), the mediator2 sprite is visible and so Mediator2 reacts to the ENTER notification.

I think I'm either going about PureMVC's notification system incorrectly or there is something that can be improved about the notification system.

The problem I am having is that a notification is sent out but during one of the mediator's reactions to this notification, a 2nd notification is send out, which is received by the other mediators before the other mediators receive the 1st notification.

For example,
1) Note1 is sent to the application.
2) Mediator1 and Mediator2 are set to receive Note1
3) Mediator1 receives Note1 first.
4) Mediator1 reacts to the note by sending out Note2
5) Mediator2 receives Note2 and changes a local boolean property from false to true
6) Mediator2 finally receives Note1.
7) Because the local property is true, Mediator2 reacts to Note1. If the local property had remained false, then Medaitor2 would not react to Note1.


I understand why Mediator2 received Note2 before it received Note1 even though Note1 was sent before Note2; however, I expected a different behavior. This is exactly the same kind of behavior as ActionScript's event system, but I would have expected the PureMVC to allow a different behavior. I would have wanted any notes to be placed in a Queue system. So if Note1 was sent, then Note1 should be received by all Mediators before any other notes even if a Mediator sends out a note while Note1 is still being sent out.


QUESTIONS:
1) What is the workaround to this issue? How can I ensure that Mediator2 does not change a local property before it has a chance to receive Note1?
2) Is there a way to ensure all mediators receive Note1 before it receives any other notes?
3) If not, should the PureMVC be changed so notes are placed in a FIFO (First In First Out.) queue? As not to break previous PureMVC applications, should PureMVC be changed so a change of a property would make the notifications be sent either using the current logic or the FIFO logic?

Thanks!

I have a question on how to architect online reporting using puremvc.
For example, I'd like to report to Comscore and/or omniture.

Usually proxies are used when you're communicating to the outside world, right? So that would mean I would create a proxy(ies) to communicate to online reporting sources. Proxies do not hear any of the framework's notifications, so that would mean I would need to create a Mediator to listen to the notifications that I would like to report. Furthermore, mediators should not tell Proxies what to do directly, so that would mean I would need a command(s) to let the reporting proxy know what notification was just dispatched.

This seems like the framework is forcing me to create extra classes when it would be simpler if the proxy could listen to the framework's notifications and thus cut all the middlemen. Is this (see below) the best way to set up a reporting architecture, or is there a better way?


1) Framework dispatches notification
2) Reporting Mediator receives notification
3) Reporting Mediator dispatches notification thru a command
4) Command tells Reporting Proxy what notification was just dispatched
5) Reporting Proxy formats the proper parameters and sends info to the reporting agent: i.e. Omniture.

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

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.

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?

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?

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?

Thanks, Cliff.
I took a look at the Flex Employee Admin demo as you suggested.
http://trac.puremvc.org/Demo_AS3_Flex_EmployeeAdmin

The demo has 3 major view components and 3 Mediators so using this demo as an an example, it would seem that it is best to have a mediator for every major View Component. But I  guess it all depends on what you personally define as "major".

In terms of my music player example, I could have a single mediator if player just was played/paused and adjusted volume. However, to the other extreme, if my player is more robust, I might need more than one mediator. For example,  I may need a mediator for each of these features: play/pause, volume, playlist, progress meter with scrubber, song ID3 data displayer, visualizer, artist slide show, etc. 

Then there is an option somewhere in the middle where I can have a few view components have their own mediators (i.e. a mediator for the playlist component, a mediator for the slideshow component) and I can have a single mediator to control multiple view components (i.e. a mediator for the components:  play/pause button, volume button, and progress meter).

Does that sound about right?

Last year it was written in the FAQs that the MIT license was being considered instead of the CC license that is currently being used for the framework.

http://puremvc.org/content/view/83/188/

"I have come around to consider that perhaps another license would be better. This will most likely be the MIT license, which is simpler. However changing all the files in the project in one sweep will be a job. "

I checked around on the forum but could not see if there has been any updates on this subject. Is the MIT license still under consideration and in the current development roadmap?