Code


Version 15 (modified by tobias, 5 years ago) (diff)

add message classes to list of criteria

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:

Justification

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

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.

Criteria

Technical criteria necessary for inclusion in the core:

  • Support message passing for anonymous users
  • Uses 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)
  • Signs cookie-based messages
  • Avoids pickling because of the obvious security concerns
  • Provide a standard, intuitive interface so that reusable apps can provide feedback related to the current session
  • Supports different, configurable "classes" (e.g., info, warning, error, etc.) of messages

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-notifyyesyesyesyesnoyesyes (via "tags")
django-flashyesnonoyesnonoyes (but not in a standard way)
django-flash-statusyesnonoyesnoyesyes, "errors" or "statuses"
django-cnotesyesnonoyesnoyesno
  • yes means yes, always
  • sometimes means under certain conditions (e.g., an engine might support large messages if the session is used, and avoid DB access if a cookie is used, but not both)
  • no means no, not in the current implementation

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