Chapter 3
Django Project Layout
<Repository_root>/
<Django_project_root>/
<Configuration_root>/
Top level: Repository Root
The top layer is the absolute path of the Project root directory.
The following files are frequently used:
Readme
DOC/
Design/
. Gitignore
Requirement.txt
Second level: Django project Root
This is typically generated by the django-admin.py startproject command
It also includes:
Configuration_root
Media/
Static/
Templates/
Various apps folders
Third level: configuration Root
It is also generated by the django-admin.py startproject
Including:
URLs. py
Settings. py, etc.
The simple layout is similar to this:
Icratings_project/
. Gitignore
Makefile
Docs/
Requirements.txt
Icratings/
Manage. py
Media/
Products/
Profiles/
Ratings/
Static/
Templates/
Icratings/
_ Init _. py
Settings/
URLs. py
Wsgi. py
You don't need to put the virtualenv's content in the volume control. You just need to put the corresponding information in requirement.txt.
Chapter 4
Django basic app Design
The prime rule for app design:
Write programs that do one thing and do it well.
Dedicated functions and loose coupling
A practical app case in a project:
Create a store and use the project directory twoscoops_project.
This Django project has:
• A flavors app to track all of our ice cream % avors and list them on our website. • A blog app for the o fficial two scoops blog.
• An Events app to display listings of our shop's events on our website: events such as strawberry sundae Sundays and fudgy first fridays.
Functions that may be added in the future:
* A shop app to allow us to sort pints by mail order.
* A tickets app, which wocould handle ticket sales for premium all-you-can-eat icecream fests.
Because tickets is not used by many applications and has complicated logic, we separate an app.
How can I name an app?
* When a word is used, it is easy to understand and maintain animals, blogs, and polls.
* Sometimes you need to adjust the name based on the URL.
Keep apps relatively small
Chapter 5
Configuration and required files
Good practical experience:
* Version control is required for all configuration files.
* Dry principle. The same configuration can be inherited.
The configuration of the development environment should not be in version control. The local debug needs to be configured, which is very different from the production environment.
See the http://www.slideshare.net/jacobian/the-best-and-worst-of-django for more Configuration
Create the settings module to process the use of different configurations
Settings/
_ Init _. py
Base. py
Local. py
Staging. py
Test. py
Production. py
It can be used as follows:
$ Django-admin.py runserver -- settings = twoscoops. settings. Local
Configuration case of a development environment:
DEBUG = true
Template_debug = debug
Email_host = 'localhost'
Email_port = 1025
Databases = {
'Default ':{
'Engine ': 'django. DB. backends. postgresql_psycopg2 ',
'Name': 'twoscoops ',
'User ':'',
'Password ':'',
'Host': 'localhost ',
'Port ':'',
}
}
Installed_apps + = ('debug _ toolbar ',)
Internal_ips = ('2017. 0.0.1 ',)
Middleware_classes + = \
('Debug _ toolbar. Middleware. debugtoolbarmiddleware ',)
Usage: $ django-admin.py runserver -- settings = twoscoops. settings. Local
Use environment variables to save passwords
Similar modules are used to process different configurations of Different developers in different environments.