The previous post made use of the Django messages framework to display a one-time message after an HTTP redirect.
Using the messages framework is simple. First, as explained in the docs, adjust your settings file:
- ‘django.contrib.messages’ is in INSTALLED_APPS
- MIDDLEWARE_CLASSES contains ‘django.contrib.sessions.middleware.SessionMiddleware’ and ‘django.contrib.messages.middleware.MessageMiddleware’
- TEMPLATE_CONTEXT_PROCESSORS contains ‘django.contrib.messages.context_processors.messages’
You can now use the framework in a view:
And display it within a template:
Boto is the de facto standard for working with the AWS API from Python. Unfortunately their SES implementation only sends text or html emails, not both. You need to drop down to their send_raw_email method to send a multi-part email.
Using this Gist as a guideline, here’s an implementation of sending a multi-part email via a library class:
You’ll also need to add your AWS access key and secret to your settings file:
You can then use the class like this:
Writing clean code means following standards, whether your own, your organizations or those of someone else.
Python likes to do things their way, so following this is a must:
Separating your views into multiple files works much the same way as models except for one difference – importing the views in __init__.py isn’t necessary unless you want to type a little less.
Without importing them in __init__, you’ll need to do this:
But if you add them, you can do the following instead:
One of the first things I noticed when I started with Django was that models and views were single files. Now I’ve read various opinions on how things should be handled (multiple modules vs. multiple files) but I’m of the opinion that clarity is always better. So even if you have a single model, I’d rather have the file be named something descriptive rather than the generic models.py.
Breaking things up into multiple files is quite straight-forward – delete models.py, create a models directory, add __init__.py and create your model classes. Here’s an example:
Note: In order for syncdb to see your models and work correctly, you’ll need to import the models in __init__.py.
Note: The Meta class is necessary for Django to associate the model correctly. Just set it to the name of your application. Otherwise syncdb won’t see your models or you’ll get a lovely error like the following when one of your models contains a foreign key:
You can then import your models like this:
David Cramer posted this excellent article back in 2011 about how they handle their config files. In a multi-environment setup (dev, stage, prod) this is paramount.
In his example he makes use of an environment variable to set which configuration to use. While this is probably ideal, it’s not always an option. As a replacement, you could use the IP address or host name of the machine:
A typical use case is to provide the user a sign out button which redirects to another page such as the homepage. The following implements this using the generic RedirectView.