Version 29 (modified by Tobias McNulty, 9 years ago) (diff)

remove API for django-notify

Message Passing For Anonymous Users

Proposal for 1.2: Django should include a contrib app, independent of contrib.auth, that facilitates message passing to anonymous users.

For more information see:


Reasons why an alternative to the existing functionality (user.message_set.create) is needed:

  • It's not possible to create messages for anonymous users
  • If the same Django user is logged in twice on different computers simultaneously, they see each others' messages
  • User messages may get wiped even if they're not actually displayed to the user
  • High-load sites want to avoid the unneeded database or cache usage

Reasons why a standard needs to be endorsed by Django and a 3rd party app will not suffice:

  • The built-in implementation is broken for a large set of use cases (above); the fact that Django actively encourages this method of messaging is a bad thing
  • Reusable apps don't know what 3rd party system to use and hence cannot rely on providing session feedback

Integrating with the Existing API

It is not possible nor desirable to integrate with the existing API because it is tied directly to a related manager on the user model and cannot be extended to support the additional functionality in this proposal (without some ugly hacks). There are several possible solutions to this conflict (we don't really need or want two messaging APIs in the core); feel free to add more:

  • In the documentation, cast the user messaging API in a vary narrow use; e.g., for administrator messages to specific users
  • Phase out user messages entirely

Existing 3rd Party Apps

There are a number of good, pre-existing applications out there that support more robust functionality, so there is no need to re-implement a solution from scratch for inclusion in Django. The existing solutions can be combined or modified to meet Django's needs. This section is meant to evaluate some of the different session/cookie message/notification engines out there for potential inclusion in Django as a contrib app. It is a work in progress so please contribute (your notification engine here) or other changes as you see fit.


Technical criteria necessary for inclusion in the core:

  • Support message passing for anonymous users
  • Use the session only as a fallback: Avoid database/cache queries if possible, but support larger messages that don't fit in a cookie (> 4kb) when needed
  • Don't lose messages if they're not displayed to the user (lazy message loading)
  • Sign cookie-based messages
  • Avoid pickling because of the obvious security concerns
  • Provide a standard, intuitive interface so that reusable apps can provide feedback related to the current session
  • Support different "classes" (e.g., info, warning, error, etc.) of messages, with the ability to specify custom classes as needed

Community criteria necessary for inclusion in the core:

  • Needs community approval/support
  • Needs to be the "de facto" standard implementation

Available Options

Name and LinkAnonymous user supportSession FallbackLazy loads messagesSigned cookiesAvoids picklingStandard interfaceClassed Messages
django-notifyyesyesyesyesyesyesyes (via "tags")
django-flashyesnonoyesnonoyes (but not in a standard way)
django-flash-statusyesnonoyesnoyesyes, "errors" or "statuses"
django-noticesyesnoyes?no (no cookie support)n/ayesyes
  • yes means yes, always or, at least, can be configured to do this
  • no means no, not in the current implementation
  • n/a means not applicable

Please update this table with new options or corrected information as necessary.

Potential API

The API is under discussion on the django-developers list. Following are a few different iterations of what it might look like:

from django.contrib import messages

request.messages.add(messages.INFO, 'message')
# or

Using messages in your template:

{% if request.messages %}
<ul class="messages">
        {% for message in request.messages %}
        <li{% if message.tags %} class="{{ message.tags }}"{% endif %}>{{ message }}</li>
        {% endfor %}
{% endif %}

Pre-configured Message Classes/Levels

Custom message classes may be easily configured for any type of message that does not fit into the pre-set classes, or where more granularity is needed. Consistency is needed regarding what a given class of message means, because multiple, independent Django apps may be combined to form a single project, and consistency is desired in the display of user feedback. It is recommended that reusable apps do not use custom message classes.

  • DEBUG: Development-related messages that will be removed before a production deployment
  • INFO: Informational messages for the user
  • SUCCESS: An action was successful, e.g. "Your profile was updated successfully"
  • WARNING: A failure did not occur but may be imminent
  • ERROR: An action was not successful or some other failure occurred

TODO Once a Solution is Chosen

  • Clean up the API, if necessary, to make it the de facto standard implementation for Django
  • Review the code and make any additional feature changes necessary to support the technical criteria necessary for inclusion

Other Considerations

  • This app will ideally take advantage of the cookie signing API that is also proposed for 1.2.
Back to Top