PureMVC Architects Lounge

I'm having a bit of a naming challenge with the FSM and its naming conventions.

Referring to the stopwatch demo

* When the FSM enters its STATE_READY,  the entering notification is RESET_DISPLAY - "resetDisplay"
* The command ResetDisplayCommand then call the proxy, proxy.resetTimer();
* The proxy updates the internal timer, and then sends the notification RESET -"StopWatchProxy/notes/reset"
* when this then picked up by ApplicationMediator, which gets the current elapsed time which the view is bound to.

The question I have, is both RESET_DISPLAY and RESET are notifications, but all the constants with "note" in the path ("notes/reset" are processed by commands, all the notifications without note ("reset") are processed by mediators.  There seems to be some sort of implied "domain" here, and I'm trying to keep my own app clean and following this convention.

I can see that by making the command process the state entering notification it can tell the proxy to update "data" and the proxy's notification then allows mediators to update the display as a result of business logic (by the command) and data changes (as a result of the proxy).

But if we had to "name" the notifications that the proxy is dispatching, what would we call them, since they ARE different from the notes that FSM is dispatching and the commands are registered for ?

Realisically whats the difference between the app mediators "reset" and the facades "notes/resetTimer"  seems like in a complex app this type of overlap is inevitable and could be very confusing since notifications are not for commands or mediators, they are consumed by anyone, so I'd see it very easy for someone to have their mediator listen for "notes/resetTimer" instead of just "reset" by accident on a larger team.

Is there some convention where "notes" from the FSM's entering/change/exit states would be named differently to the apps "view related" notes not just in the class they are defined in, but how they are defined ?


Cheers
Grant

due to the overwhelming responses :)  I've created two constants classes

DTDChallengeNotifications  (this is for "system" or "regular" notifications)
DTDChallengeStateChangeNotifications ( this is for exiting/entering/change notifications)

So far so good, and I have to say the FSM is saving me tons of complexity that I had without it.