class storage.fallback.FallbackStorage This class first uses CookieStorage, and falls back to using SessionStorage for the messages that could not fit in a single cookie. It also requires Django’s contrib.sessions application. This behavior avoids writing to the session whenever possible. It should provide the best performance in the general case. FallbackStorage is the default storage class. If it isn’t suitable to your needs, you can select another storage class by setting MESSAGE_STORAGE

class storage.cookie.CookieStorage This class stores the message data in a cookie (signed with a secret hash to prevent manipulation) to persist notifications across requests. Old messages are dropped if the cookie data size would exceed 2048 bytes.

class storage.base.Message When you loop over the list of messages in a template, what you get are instances of the Message class. It’s quite a simple object, with only a few attributes: message: The actual text of the message. level: An integer describing the type of the message (see the message levels section above). tags: A string combining all the message’s tags (extra_tags and level_tag) separated by spaces. extra_tags: A string containing custom tags for this message, separated by

class storage.base.BaseStorage To write your own storage class, subclass the BaseStorage class in django.contrib.messages.storage.base and implement the _get and _store methods.

class MessageMiddleware [source] Enables cookie- and session-based message support. See the messages documentation.

get_messages(request) [source] In your template, use something like: {% if messages %} <ul class="messages"> {% for message in messages %} <li{% if message.tags %} class="{{ message.tags }}"{% endif %}>{{ message }}</li> {% endfor %} </ul> {% endif %} If you’re using the context processor, your template should be rendered with a RequestContext. Otherwise, ensure messages is available to the template context. Even if you know there is only just one message

add_message(request, level, message, extra_tags='', fail_silently=False) [source]

To define a many-to-one relationship, use ForeignKey: from django.db import models class Reporter(models.Model): first_name = models.CharField(max_length=30) last_name = models.CharField(max_length=30) email = models.EmailField() def __str__(self): # __unicode__ on Python 2 return "%s %s" % (self.first_name, self.last_name) class Article(models.Model): headline = models.CharField(max_length=100) pub_date = models.DateField() reporter = models.

To define a many-to-many relationship, use ManyToManyField. In this example, an Article can be published in multiple Publication objects, and a Publication has multiple Article objects: from django.db import models class Publication(models.Model): title = models.CharField(max_length=30) def __str__(self): # __unicode__ on Python 2 return self.title class Meta: ordering = ('title',) class Article(models.Model): headline = models.CharField(max_leng

Websites generally need to serve additional files such as images, JavaScript, or CSS. In Django, we refer to these files as “static files”. Django provides django.contrib.staticfiles to help you manage them. This page describes how you can serve these static files. Configuring static files Make sure that django.contrib.staticfiles is included in your INSTALLED_APPS. In your settings file, define STATIC_URL, for example: STATIC_URL = '/static/' In your templates, either hardcode the url lik