Patterns for Web Development

Request handling (GET and POST)

• Always redirect after a POST

• Django Pattern: Processing POST Requests in the Same View as Renders the Form

  This time we’ll use a slightly different approach, one that’s actually a very common pattern in Django, which is to use the same view to process POST requests as to render the form that they come from. Whilst this doesn’t fit the REST-ful URL model quite as well, it has the important advantage that the same URL can display a form, and display any errors encountered in processing the user’s input.

Coding Conventions

• The convention I’m using is that URLs without a trailing slash are "action" URLs which modify the database.

Site Operation

• always run your web apps as a nonroot user

• Each site (staging, live, or any other website) has its own folder. Within that we have a separate folder for the source code, the database, and the static files

• That’s the Debian/Ubuntu preferred way of saving Nginx configurations—​the real config file in sites-available, and a symlink in sites-enabled; the idea is that it makes it easier to switch sites on or off.

• Test-Drive Server Configuration and Deployment

Django

Complex Views

In Django, a complex view is a code smell. Could some of that logic be pushed out to a form? Or to some custom methods on the model class? Or maybe even to a non-Django module that represents your business logic?

Thin views *

If you find yourself looking at complex views, and having to write a lot of tests for them, it’s time to start thinking about whether that logic could be moved elsewhere: possibly to a form, like we’ve done here. Another possible place would be a custom method on the model class. And—​once the complexity of the app demands it—​out of Django-specific files and into your own classes and functions, that capture your core business logic.