More on Constants placement

[Sammi]

Hi,

I have read the threads and FAQ on where to place constants and they make sense.  I prefer to put them in the ApplicationFacade, even if they are quite many, but I can also understand why some put them in a seperate file.  If I understand the recommendations correctly constants for notifications from the commands and mediators are declared in the application facade but constants for notifications from the model are declared in the proxies. 

What I want to understand better is how you handle constants in "view components".  A view component has a constant for an event that it dispatches.  Let's call it "LOGIN". The mediator for the view listens for the event and sends a LOGIN notification.

Should I declare a LOGIN constant in the application facade for that notification or can I use the constant from the view component:

sendNotification(LoginView.LOGIN)

It doesn't seem like a good idea but still most of the views actually trigger an event that results in the mediators sending out a notification and it bothers me to be defining the same constant twice.

Hmmmm....

Sammi

[puremvc]

I generally add the constant to the view component. And I end up defining some corresponding constant within the concrete Facade. The button event called LOGIN will trigger an TRY_LOGIN notification.

I could put the constants in a separate file and have the view component import them but I'd rather not pushe anything into the component. And I don't want to have other actors be interested in a note name defined on a view component.

-=Cliff>

[puremvc]

There is of course a middle ground, which is to define a custom event, define the constant there, have the view component dispatch it and the listening mediator sends a notification reusing the constant defined on the event. This way, at least it is not the view component defining it, and you don't use 2 constants.

This is also good if the view component is sending a bunch of data, since you can wad it all up and toss it at the PureMVC apparatus. The mediator doesn't have to 'pluck' the data out of the view component, and can just send the event in the body of a notification of the same way. You are in essence 'tunneling' the event to a command or other mediator(s), who'll be prepared to work with that event.

This concept also works in MultiCore as a method of routing messages. The same problem exists there when we define custom Pipe Message classes and pass them between cores/modules. Rather than defining constants inside a module for responding to a given message (the duplicated constant scenario again), we can just reuse the message name constant as a notification constant, and send the incoming message out in the body of a notification by the same name. The listening mediator(s) or command will be prepared to work with that message class.

So events and messages can be considered data carriers that parts of the app might work with in addition to the built in simple notification system.
-=Cliff>   

[Sammi]

Thank you for your time.

I think I will end up doing like I have been doing now that I know that it is a commonly used method.  That is to define a constant in the mediator that corresponds to the view components mediator.

I wish I could figure out how to make an FDT template for a constant.  It would be cool to be able to add a constant template and then as you write the constant's name (SOME_NOTIFICATION), FDT would write "someNotification" or event just "some_notification" for you in the value of the constant

Best,
Sammi

[puremvc]

Defining the constant in the mediator and sending it from the view component is exactly what you *don't* want to do. Then the view component must import the mediator and thus your view component is no longer portable. The view component should have zero dependencies on the PureMVC apparatus. It would be better to do it the other way around and define it on the view component and if a command has to be registered or a mediator interested, then the facade or interested mediator imports the view class to get at the constant.

-=Cliff>

[Sammi]

Ooops,

I meant to say "That is to define a constant in the facade ..."

So the view components have their own constants for their normal events and corresponding notification constants a declared in the facade.

- LoginView sends a LoginView.LOGIN event when the login button is clicked
- LoginMediator listens for the event and the sends ApplicationFacade.LOGIN notification

Best,
Sammi