How do I break up the controllers (views) into cohesive files in a Django project?

Question

I am currently working through the tutorial on Django's website. Upon completing the following command:

python manage.py startapp polls

it creates the following structure:

polls/
    __init__.py
    models.py
    tests.py
    views.py

As I was going through the tutorial it occurred to me that the views file could grow to this huge incohesive monolithic file that has every action in the entire web application.

Is there a way to break this file up into cohesive classes or files? I tried changing the settings.py and the url.py to point to a different directory, but it appears that the script that generates the file structure creates a "views" module when it creates the file, and I don't see a way to change/override this behavior from the script.

Answer 1

Each app you create for the project will have its own views.py file (assuming it uses views), so you don't need to worry about it becoming monolithic.

Just make sure to keep your apps' functionality focused.

From the Django docs:

Projects vs. apps

What's the difference between a project and an app? An app is a Web application that does something -- e.g., a weblog system, a database of public records or a simple poll app. A project is a collection of configuration and apps for a particular Web site. A project can contain multiple apps. An app can be in multiple projects.

Answer 2

I worked though that tutorial recently. I had figured that most of the "core" logic would go in to various classes or methods in other supporting files. Then the views.py would contain basic calls to setup and execute the methods.

Given this design, I'd expect that a single view function might end up with 3 to 5 lines of code. Setup, execute method and return.

Basically, what I mean is an implementation of the Facade pattern.

I expect the tutorial avoided this approach because it adds levels of redirection (misdirection?) that can make it harder for a introductee to follow the code.

Answer 3

You could split up views in a similar manner to how this blog entry splits models

http://www.nomadjourney.com/2009/11/splitting-up-django-models/

eg

/myapp

    * /views
          o __init__.py
          o bar.py
          o foo.py

with appropriate import statements in the __init__.py file

This might be appropriate for an expanding app. Also views are more flexible than models in the way they can be structured so you could do backend/ members/ frontend/ modules or just admin_views.py etc.

Answer 4

The view functions don't have to be in views.py, they can be anywhere, as long as they're mapped properly in urls.py. So it's up to you how you organize your project.

but it appears that the script that generates the file structure creates a "views" module when it creates the file, and I don't see a way to change/override this behavior from the script.

You can totally ignore that script and what it generates. It doesn't do anything magical behind the scenes; it just creates those files for you.

Answer 5

One of the things I do to make my apps' views more compact is to factor my views pretty aggressively. I hate writing any code twice, so this comes naturally for me. Anywhere I can, I use a generic view to perform the needed actions. A good percentage of the functionality of my views is decorators, which perform common actions on the views that need it.

for instance, I have a post_limit decorator that checks if the user has recently modified any instance in a certain model(configurable view by view) and produces an error if she has, as a means of flood protection.

In fact, many views work so similarly, that they don't even get their own function bodies, I just wrap generic views with the appropriate decorators, and the only views that get much custom code are aggregation type sites, such as the landing page, that collect lots of different information in subtle ways, so that they look 'just right'