Should messages reside in the controller or model for a web site/web app?

In Django, there's the existence of a message fra开发者_运维问答mework which notifies the user after an action is performed. For instance, from the views.py there might something like:

if success:
    messages.success(request, 'Update Successful')
else:
    messages.warning(request, 'Something is missing')

I believe Rails have something similar with:

flash[:notice] = 'Something is missing'

Should the messages above be hard-coded in the controller?

If I understand your question, you are asking whether or not you should hard-code a string value into your code. In compiled languages, you often use a reference to a string, instead of entering the actual string. ala:

message.success(request, message_resource.success )

This gives you the freedom to change the string value without re-compiling the code, and has a performance benefit in some instances.

Because Python is dynamic this really isn't required, but depending on the size of the project, may be beneficial.

Imagine a situation where the software is used by people speaking different languages, you could detect the required language somewhere else in your code and initialize message_resource.success, as well as any other strings, to be in said language.

here is a simple example:

german.py

# german language messages
success = "Sie folgten!"
failure = "Sie fallen aus!"

english.py

#english language messages
success = "You succeeded!"
failure = "You fail!"

main.py

# main

# import english language
message_resource = __import__('english');

print message_resource.success
print message_resource.failure

# import german language
message_resource = __import__('german');

print message_resource.success
print message_resource.failure

In Rails any marshallable object can be put in the flash. Therefore it is better to do it in the view.

<% if flash[:notices] && flash[:notices][:missing] %>
<div><%= t("Somethign missing") %></div>
<% end %>

Putting text and translations in the controllers is indeed a bit ugly..

Messages are events. Things that happen. Which is what the "controller" part of MVC is all about. The "how".

(Django calls this "view functions".)

The model is (mostly) stuff that's static, final, persistent. Passive. The "what".

Things happen to the model. Things are initiated by the controller.

Messages come from the controller for presentation to the person.

It's possible that a model's method might need to provide some evidence or information on a state change. This is not an example of a message being created by the model. If the model has methods that do mutation/update/state change, then you have to break things into two pieces.

The "controller" (i.e., Django view function) must use the model's API to make the state change and collect any information on that state change.

The "controller" (the view function) does I18N translation and presents the message.

generic examples

• Model: The method is_missing() would go in the model, if it is dependent only on the data.

• Controller: Marshalling data from the model for the view: missing = Suff.get_by_id(1).is_missing()

• View: <span>{$missing}<span>

But exactly where you draw those lines is always up for debate. In your example, I would say flash, success, and warning are over-stepping their bounds on how to present the data and would be better in the view since they are generic data presenters.