Django Reusable App Conventions

What is a reusable app?

A reusable Django app, is an app that is easily plugged into a project, providing a very specific piece of functionality. They should be focused and follow the Unix philosophy of "Do one thing and do it well." Please refer to James Bennett's Djangocon talk on the subject for more info.

How do I distribute my app?

Django should be using the standard Python Package Index aka Pypi or the Cheese Shop. I wrote a tutorial about how to easily package and upload your app to Pypi. All reusable apps should be uploading to Pypi.

If you upload your app to Pypi, it is generally a good idea to prefix your project name with "django-"

Also note, that when below when we refer to the default place for something as a file, that also means that you can make a directory of that same name; as per normal python.

Models

Placed in APP/models (.py or a directory)
Follow Django's model conventions

Urls

Placed in APP/urls (.py or a directory)
Should have a name attribute so they are reversible; APP_MODEL_VIEW, for example blog_post_detail or blog_post_list.

Views

Placed in APP/views (.py or a directory)
Can be any callable python function.
These should provide sane defaults, easily overridable:

Example:

  def register(request, success_url=None,
             form_class=RegistrationForm
             template_name='registration/registration_form.html',
             extra_context=None):

Admin

Not required
Placed in APP/admin.py
Admin classes for a MODEL are called MODELAdmin

Templates

Placed in APP/templates/APP/template.html

In an effort to standardize the block names in Django templates, I have proposed the following blocks for common usage.

{% block title %}

This will be the block where you define the title of the page. Presumably your base.html will define your Site's name (perhaps even using the Sites framework) outside of this tag, to be places on all pages.

{% block extra_head %}

I think that this is a good one that most people are already using in some form or another. In your base template you have a set of things in your <head> that every page will have. However, a lot of other pages need things that they also want to put in the head of a document, like RSS feeds, Javascript, CSS, and all the other things that should go in the head. You can and probably will have other specialized blocks (like title above) that will fill in other parts of the head too.

{% block body %}

This tag will be placed around the entire body section of the page. This allows you to create pages in your app that replace the entire page, not just the content. This won't be used a lot, but it's a really handy tag to have when you need it. If you haven't noticed, I've been trying to keep tag names consistent with their html tag names whenever possible.

{% block menu %}

This would be where your menu goes. It would be the site-wide navigation, and not a per-page type of navigation.

{% block content %}

This will be the place where you define the content on a page. This will presumably change on every page. It will not include any site navigation, headers, footers, or anything else that would belong in a base template.

Other possible blocks

{% block content_title %}

This would be where the "title" of a content block would be. It includes the title of a blog. It can also include some kind of navigation between content, or other things like that. Presumably something that isn't the main pages content. I don't know if this should go inside the content tag and have a main_content as opposed to the content tag proposed above.

{% block header %} {% block footer %}

Any text area in the header of footer that might change on a page-by-page basis.

{% block body_id %} {% block body_class %}

This would be used to set the class or id of the body tag in the document. This is useful to set for styling and other properties.

{% block [section]_menu %} {% block page_menu %}

This would be opposed to the menu block proposed above. It would be for the section or page.

Documentation

Placed in a docs directory at the same level as the APP directory (you do have a top-level directory above your app, right?)
Can contain templates, for reference

Forms

Placed in APP/forms.py

Template Tags

Placed in APP/templatetags/APP_tags.py

Proposed template tag syntax

as (Context Var): This is used to set a variable in the context of the page
for (object or app.model): This is used to designate an object for an action to be taken on.
limit (num): This is used to limit a result to a certain number of results.
exclude (object or pk): The same as for, but is used to exclude things of that type.

Tests

Placed in APP/tests (.py or a directory)
Fixtures are placed in APP/fixtures/fixture.json
Usually overrides Django's testcase

Middleware

Placed in APP/middleware.py
As minimal as possible

Context Processors

Placed in APP/context_processors.py

Managers

Placed in APP/managers.py

Feeds

Placed in APP/feeds.py

Surfing in Kansas