notifications, commands and mediators

[hesten]

Hi All

If a notification has an associated command and a Mediator is interested in this notification, what is the order of execution?

Say the command modifies the model and the mediator needs this modification. Can this be handled on the same notification (by order of execution) or should it be implemented using another notification?

[puremvc]

It depends on the order they were registered. If the command was registered at startup and the mediator registered subsequently, then the command will be notified first.

Just a word to the wise, don't set your self up with a situation where order of execution matters. The reason is it's not clear that there is an inherent dependency on the order of registration. Later if there is a refactoring and the command gets registered after and not before the mediator, then the code will break and you'll wonder why. 

Instead, make a series of notifications instead of just one.

For instance if you have a DATA_RETRIEVED note and both a command and a mediator are interested, but the mediator relies on the command to have done its work first, then have the command be registered to the note and then at the end of the command's execute method, send a DATA_PROCESSED note that the mediator is interested in.

Although the order might be the same and you save a few cycles, this is an unambiguous thread of execution that another developer (or you in 6 months) can follow clearly.

-=Cliff>

[hesten]

That makes sense. It's just that I feel like notification names are piling up in my ApplicationFacade. I've seen example projects that put notification names on Proxies (I think), and I've seen suggested that you put notification names in a seperate file?

I guess I'm looking for at way of ordering the notification names, and thought I could cut a corner by using just one under certain circumstances

[Jason MacDonald]

I tended to put my note names in a *Constants.as file to keep them out of my Facade. I also put all the notification constant names that a Proxy sends in the Proxy itself so they stay self contained and reusable, without having to drag along the *Constants.as file when reusing them.

It also creates a clear distinction when showing interest in a notification from a Proxy (ie: DataProxy.DATA_READY instead of ApplicationFacade.DATA_READY). The proxy is the only one likely to send such a notification so it makes sense to have it in the Proxy itself. A DATA_READY note send from a different proxy or a command would likely hold a different meaning/data then the DataProxy.DATA_READY note.

[Steve]

Picking up on this thread rather late, but it addresses my current questions.

Jason - that was just the confirmation I was looking for regarding proxy notification names and makes complete sense for all the reasons you state. My question is - does this apply to Mediators who send their own notifications too?

[puremvc]

@Steve, no you don't want the mediators defining their own notes so much. Proxies you do because one day you might take the entire model and use it in another app, so you want that portability. Not so with Mediators, which tend to be tied to the app they are a part of. Also, you want to loosely couple the actors in the view, becaus it is most subject to major refactoring. You might have a mediator whose responsibilies becomes cumbersome when its view component adds several children, so you split it into two mediators or more. At that point if you define notes on the mediators, now you have to go hunt sown all the interested parties.

For this reason its best to keep the view and controller related notes all in one place for the app. Put them in a constants file as Jason suggested if there are a lot of them.

-=Cliff>

[Steve]

great, thanks Cliff - just what I needed to know, and again makes sense.