Simplified default project template.
Squashed commit of:
commit 508ec9144b35c50794708225b496bde1eb5e60aa
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 22:50:55 2013 +0100
Tweaked default settings file.
* Explained why BASE_DIR exists.
* Added a link to the database configuration options, and put it in its
own section.
* Moved sensitive settings that must be changed for production at the
top.
commit 6515fd2f1aa73a86dc8dbd2ccf512ddb6b140d57
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 14:35:21 2013 +0100
Documented the simplified app & project templates in the changelog.
commit 2c5b576c2ea91d84273a019b3d0b3b8b4da72f23
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 13:59:27 2013 +0100
Minor fixes in tutorials 5 and 6.
commit 55a51531be8104f21b3cca3f6bf70b0a7139a041
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 13:51:11 2013 +0100
Updated tutorial 2 for the new project template.
commit 29ddae87bdaecff12dd31b16b000c01efbde9e20
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 11:58:54 2013 +0100
Updated tutorial 1 for the new project template.
commit 0ecb9f6e2514cfd26a678a280d471433375101a3
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 11:29:13 2013 +0100
Adjusted the default URLconf detection to account for the admin.
It's now enabled by default.
commit 5fb4da0d3d09dac28dd94e3fde92b9d4335c0565
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 10:36:55 2013 +0100
Added security warnings for the most sensitive settings.
commit 718d84bd8ac4a42fb4b28ec93965de32680f091e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:24:06 2013 +0100
Used an absolute path for the SQLite database.
This ensures the settings file works regardless of which directory
django-admin.py / manage.py is invoked from.
BASE_DIR got a +1 from a BDFL and another core dev. It doesn't involve
the concept of a "Django project"; it's just a convenient way to express
relative paths within the source code repository for non-Python files.
Thanks Jacob Kaplan-Moss for the suggestion.
commit 1b559b4bcda622e10909b68fe5cab90db6727dd9
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:22:40 2013 +0100
Removed STATIC_ROOT from the default settings template.
It isn't necessary in development, and it confuses beginners to no end.
Thanks Carl Meyer for the suggestion.
commit a55f141a500bb7c9a1bc259bbe1954c13b199671
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 23:21:43 2013 +0100
Removed MEDIA_ROOT/URL from default settings template.
Many sites will never deal with user-uploaded files, and MEDIA_ROOT is
complicated to explain.
Thanks Carl Meyer for the suggestion.
commit 44bf2f2441420fd9429ee9fe1f7207f92dd87e70
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:22:09 2013 +0100
Removed logging config.
This configuration is applied regardless of the value of LOGGING;
duplicating it in LOGGING is confusing.
commit eac747e848eaed65fd5f6f254f0a7559d856f88f
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:05:31 2013 +0100
Enabled the locale middleware by default.
USE_I18N is True by default, and doesn't work well without
LocaleMiddleware.
commit d806c62b2d00826dc2688c84b092627b8d571cab
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:03:16 2013 +0100
Enabled clickjacking protection by default.
commit 99152c30e6a15003f0b6737dc78e87adf462aacb
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 22:01:48 2013 +0100
Reorganized settings in logical sections, and trimmed comments.
commit d37ffdfcb24b7e0ec7cc113d07190f65fb12fb8a
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:54:11 2013 +0100
Avoided misleading TEMPLATE_DEBUG = DEBUG.
According to the docs TEMPLATE_DEBUG works only when DEBUG = True.
commit 15d9478d3a9850e85841e7cf09cf83050371c6bf
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:46:25 2013 +0100
Removed STATICFILES_FINDERS/TEMPLATE_LOADERS from default settings file.
Only developers with special needs ever need to change these settings.
commit 574da0eb5bfb4570883756914b4dbd7e20e1f61e
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:45:01 2013 +0100
Removed STATICFILES/TEMPLATES_DIRS from default settings file.
The current best practice is to put static files and templates in
applications, for easier testing and deployment.
commit 8cb18dbe56629aa1be74718a07e7cc66b4f9c9f0
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:24:16 2013 +0100
Removed settings related to email reporting from default settings file.
While handy for small scale projects, it isn't exactly a best practice.
commit 8ecbfcb3638058f0c49922540f874a7d802d864f
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 18:54:43 2013 +0100
Documented how to enable the sites framework.
commit 23fc91a6fa67d91ddd9d71b1c3e0dc26bdad9841
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:28:59 2013 +0100
Disabled the sites framework by default.
RequestSite does the job for single-domain websites.
commit c4d82eb8afc0eb8568bf9c4d12644272415e3960
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Tue Jan 29 00:08:33 2013 +0100
Added a default admin.py to the application template.
Thanks Ryan D Hiebert for the suggestion.
commit 4071dc771e5c44b1c5ebb9beecefb164ae465e22
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 10:59:49 2013 +0100
Enabled the admin by default.
Everyone uses the admin.
commit c807a31f8d89e7e7fd97380e3023f7983a8b6fcb
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 10:57:05 2013 +0100
Removed admindocs from default project template.
commit 09e4ce0e652a97da1a9e285046a91c8ad7a9189c
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:32:52 2013 +0100
Added links to the settings documentation.
commit 5b8f5eaef364eb790fcde6f9e86f7d266074cca8
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 11:06:54 2013 +0100
Used a significant example for URLconf includes.
commit 908e91d6fcee2a3cb51ca26ecdf12a6a24e69ef8
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 16:22:31 2013 +0100
Moved code comments about WSGI to docs, and rewrote said docs.
commit 50417e51996146f891d08ca8b74dcc736a581932
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Mon Jan 28 15:51:50 2013 +0100
Normalized the default application template.
Removed the default test that 1 + 1 = 2, because it's been committed
way too many times, in too many projects.
Added an import of `render` for views, because the first view will
often be:
def home(request):
return render(request, "mysite/home.html")
This commit is contained in:
Aymeric Augustin
parent
21ea58b8cc
commit
3f1c7b7053
|
|
@ -0,0 +1,3 @@
|
|||
from django.contrib import admin
|
||||
|
||||
# Register your models here.
|
||||
|
|
@ -1,16 +1,3 @@
|
|||
"""
|
||||
This file demonstrates writing tests using the unittest module. These will pass
|
||||
when you run "manage.py test".
|
||||
|
||||
Replace this with more appropriate tests for your application.
|
||||
"""
|
||||
|
||||
from django.test import TestCase
|
||||
|
||||
|
||||
class SimpleTest(TestCase):
|
||||
def test_basic_addition(self):
|
||||
"""
|
||||
Tests that 1 + 1 always equals 2.
|
||||
"""
|
||||
self.assertEqual(1 + 1, 2)
|
||||
# Create your tests here.
|
||||
|
|
|
|||
|
|
@ -1 +1,3 @@
|
|||
from django.shortcuts import render
|
||||
|
||||
# Create your views here.
|
||||
|
|
|
|||
|
|
@ -1,152 +1,82 @@
|
|||
# Django settings for {{ project_name }} project.
|
||||
"""
|
||||
Django settings for {{ project_name }} project.
|
||||
|
||||
DEBUG = True
|
||||
TEMPLATE_DEBUG = DEBUG
|
||||
For more information on this file, see
|
||||
https://docs.djangoproject.com/en/{{ docs_version }}/topics/settings/
|
||||
|
||||
ADMINS = (
|
||||
# ('Your Name', 'your_email@example.com'),
|
||||
)
|
||||
For the full list of settings and their values, see
|
||||
https://docs.djangoproject.com/en/{{ docs_version }}/ref/settings/
|
||||
"""
|
||||
|
||||
MANAGERS = ADMINS
|
||||
# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
|
||||
import os
|
||||
BASE_DIR = os.path.dirname(os.path.dirname(__file__))
|
||||
|
||||
DATABASES = {
|
||||
'default': {
|
||||
'ENGINE': 'django.db.backends.', # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
|
||||
'NAME': '', # Or path to database file if using sqlite3.
|
||||
# The following settings are not used with sqlite3:
|
||||
'USER': '',
|
||||
'PASSWORD': '',
|
||||
'HOST': '', # Empty for localhost through domain sockets or '127.0.0.1' for localhost through TCP.
|
||||
'PORT': '', # Set to empty string for default.
|
||||
}
|
||||
}
|
||||
|
||||
# Local time zone for this installation. Choices can be found here:
|
||||
# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
|
||||
# although not all choices may be available on all operating systems.
|
||||
# In a Windows environment this must be set to your system time zone.
|
||||
TIME_ZONE = 'America/Chicago'
|
||||
# Quick-start development settings - unsuitable for production
|
||||
|
||||
# Language code for this installation. All choices can be found here:
|
||||
# http://www.i18nguy.com/unicode/language-identifiers.html
|
||||
LANGUAGE_CODE = 'en-us'
|
||||
|
||||
SITE_ID = 1
|
||||
|
||||
# If you set this to False, Django will make some optimizations so as not
|
||||
# to load the internationalization machinery.
|
||||
USE_I18N = True
|
||||
|
||||
# If you set this to False, Django will not format dates, numbers and
|
||||
# calendars according to the current locale.
|
||||
USE_L10N = True
|
||||
|
||||
# If you set this to False, Django will not use timezone-aware datetimes.
|
||||
USE_TZ = True
|
||||
|
||||
# Absolute filesystem path to the directory that will hold user-uploaded files.
|
||||
# Example: "/var/www/example.com/media/"
|
||||
MEDIA_ROOT = ''
|
||||
|
||||
# URL that handles the media served from MEDIA_ROOT. Make sure to use a
|
||||
# trailing slash.
|
||||
# Examples: "http://example.com/media/", "http://media.example.com/"
|
||||
MEDIA_URL = ''
|
||||
|
||||
# Absolute path to the directory static files should be collected to.
|
||||
# Don't put anything in this directory yourself; store your static files
|
||||
# in apps' "static/" subdirectories and in STATICFILES_DIRS.
|
||||
# Example: "/var/www/example.com/static/"
|
||||
STATIC_ROOT = ''
|
||||
|
||||
# URL prefix for static files.
|
||||
# Example: "http://example.com/static/", "http://static.example.com/"
|
||||
STATIC_URL = '/static/'
|
||||
|
||||
# Additional locations of static files
|
||||
STATICFILES_DIRS = (
|
||||
# Put strings here, like "/home/html/static" or "C:/www/django/static".
|
||||
# Always use forward slashes, even on Windows.
|
||||
# Don't forget to use absolute paths, not relative paths.
|
||||
)
|
||||
|
||||
# List of finder classes that know how to find static files in
|
||||
# various locations.
|
||||
STATICFILES_FINDERS = (
|
||||
'django.contrib.staticfiles.finders.FileSystemFinder',
|
||||
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
|
||||
# 'django.contrib.staticfiles.finders.DefaultStorageFinder',
|
||||
)
|
||||
|
||||
# Make this unique, and don't share it with anybody.
|
||||
# SECURITY WARNING: keep the secret key used in production secret!
|
||||
# Hardcoded values can leak through source control. Consider loading
|
||||
# the secret key from an environment variable or a file instead.
|
||||
SECRET_KEY = '{{ secret_key }}'
|
||||
|
||||
# List of callables that know how to import templates from various sources.
|
||||
TEMPLATE_LOADERS = (
|
||||
'django.template.loaders.filesystem.Loader',
|
||||
'django.template.loaders.app_directories.Loader',
|
||||
# 'django.template.loaders.eggs.Loader',
|
||||
# SECURITY WARNING: don't run with debug turned on in production!
|
||||
DEBUG = True
|
||||
|
||||
TEMPLATE_DEBUG = True
|
||||
|
||||
|
||||
# Application definition
|
||||
|
||||
INSTALLED_APPS = (
|
||||
'django.contrib.admin',
|
||||
'django.contrib.auth',
|
||||
'django.contrib.contenttypes',
|
||||
'django.contrib.sessions',
|
||||
'django.contrib.messages',
|
||||
'django.contrib.staticfiles',
|
||||
)
|
||||
|
||||
MIDDLEWARE_CLASSES = (
|
||||
'django.middleware.common.CommonMiddleware',
|
||||
'django.contrib.sessions.middleware.SessionMiddleware',
|
||||
'django.middleware.locale.LocaleMiddleware',
|
||||
'django.middleware.common.CommonMiddleware',
|
||||
'django.middleware.csrf.CsrfViewMiddleware',
|
||||
'django.contrib.auth.middleware.AuthenticationMiddleware',
|
||||
'django.contrib.messages.middleware.MessageMiddleware',
|
||||
# Uncomment the next line for simple clickjacking protection:
|
||||
# 'django.middleware.clickjacking.XFrameOptionsMiddleware',
|
||||
'django.middleware.clickjacking.XFrameOptionsMiddleware',
|
||||
)
|
||||
|
||||
ROOT_URLCONF = '{{ project_name }}.urls'
|
||||
|
||||
# Python dotted path to the WSGI application used by Django's runserver.
|
||||
WSGI_APPLICATION = '{{ project_name }}.wsgi.application'
|
||||
|
||||
TEMPLATE_DIRS = (
|
||||
# Put strings here, like "/home/html/django_templates" or "C:/www/django/templates".
|
||||
# Always use forward slashes, even on Windows.
|
||||
# Don't forget to use absolute paths, not relative paths.
|
||||
)
|
||||
|
||||
INSTALLED_APPS = (
|
||||
'django.contrib.auth',
|
||||
'django.contrib.contenttypes',
|
||||
'django.contrib.sessions',
|
||||
'django.contrib.sites',
|
||||
'django.contrib.messages',
|
||||
'django.contrib.staticfiles',
|
||||
# Uncomment the next line to enable the admin:
|
||||
# 'django.contrib.admin',
|
||||
# Uncomment the next line to enable admin documentation:
|
||||
# 'django.contrib.admindocs',
|
||||
)
|
||||
# Database
|
||||
# https://docs.djangoproject.com/en/{{ docs_version }}/ref/settings/#databases
|
||||
|
||||
# A sample logging configuration. The only tangible logging
|
||||
# performed by this configuration is to send an email to
|
||||
# the site admins on every HTTP 500 error when DEBUG=False.
|
||||
# See http://docs.djangoproject.com/en/dev/topics/logging for
|
||||
# more details on how to customize your logging configuration.
|
||||
LOGGING = {
|
||||
'version': 1,
|
||||
'disable_existing_loggers': False,
|
||||
'filters': {
|
||||
'require_debug_false': {
|
||||
'()': 'django.utils.log.RequireDebugFalse'
|
||||
}
|
||||
},
|
||||
'handlers': {
|
||||
'mail_admins': {
|
||||
'level': 'ERROR',
|
||||
'filters': ['require_debug_false'],
|
||||
'class': 'django.utils.log.AdminEmailHandler'
|
||||
}
|
||||
},
|
||||
'loggers': {
|
||||
'django.request': {
|
||||
'handlers': ['mail_admins'],
|
||||
'level': 'ERROR',
|
||||
'propagate': True,
|
||||
},
|
||||
DATABASES = {
|
||||
'default': {
|
||||
'ENGINE': 'django.db.backends.sqlite3',
|
||||
'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
|
||||
}
|
||||
}
|
||||
|
||||
# Internationalization
|
||||
# https://docs.djangoproject.com/en/{{ docs_version }}/topics/i18n/
|
||||
|
||||
LANGUAGE_CODE = 'en-us'
|
||||
|
||||
TIME_ZONE = 'UTC'
|
||||
|
||||
USE_I18N = True
|
||||
|
||||
USE_L10N = True
|
||||
|
||||
USE_TZ = True
|
||||
|
||||
|
||||
# Static files (CSS, JavaScript, Images)
|
||||
# https://docs.djangoproject.com/en/{{ docs_version }}/howto/static-files/
|
||||
|
||||
STATIC_URL = '/static/'
|
||||
|
|
|
|||
|
|
@ -1,17 +1,12 @@
|
|||
from django.conf.urls import patterns, include, url
|
||||
|
||||
# Uncomment the next two lines to enable the admin:
|
||||
# from django.contrib import admin
|
||||
# admin.autodiscover()
|
||||
from django.contrib import admin
|
||||
admin.autodiscover()
|
||||
|
||||
urlpatterns = patterns('',
|
||||
# Examples:
|
||||
# url(r'^$', '{{ project_name }}.views.home', name='home'),
|
||||
# url(r'^{{ project_name }}/', include('{{ project_name }}.foo.urls')),
|
||||
# url(r'^blog/', include('blog.urls')),
|
||||
|
||||
# Uncomment the admin/doc line below to enable admin documentation:
|
||||
# url(r'^admin/doc/', include('django.contrib.admindocs.urls')),
|
||||
|
||||
# Uncomment the next line to enable the admin:
|
||||
# url(r'^admin/', include(admin.site.urls)),
|
||||
url(r'^admin/', include(admin.site.urls)),
|
||||
)
|
||||
|
|
|
|||
|
|
@ -1,32 +1,14 @@
|
|||
"""
|
||||
WSGI config for {{ project_name }} project.
|
||||
|
||||
This module contains the WSGI application used by Django's development server
|
||||
and any production WSGI deployments. It should expose a module-level variable
|
||||
named ``application``. Django's ``runserver`` and ``runfcgi`` commands discover
|
||||
this application via the ``WSGI_APPLICATION`` setting.
|
||||
|
||||
Usually you will have the standard Django WSGI application here, but it also
|
||||
might make sense to replace the whole Django WSGI application with a custom one
|
||||
that later delegates to the Django one. For example, you could introduce WSGI
|
||||
middleware here, or combine a Django application with an application of another
|
||||
framework.
|
||||
It exposes the WSGI callable as a module-level variable named ``application``.
|
||||
|
||||
For more information on this file, see
|
||||
https://docs.djangoproject.com/en/{{ docs_version }}/howto/deployment/wsgi/
|
||||
"""
|
||||
import os
|
||||
|
||||
# We defer to a DJANGO_SETTINGS_MODULE already in the environment. This breaks
|
||||
# if running multiple sites in the same mod_wsgi process. To fix this, use
|
||||
# mod_wsgi daemon mode with each site in its own daemon process, or use
|
||||
# os.environ["DJANGO_SETTINGS_MODULE"] = "{{ project_name }}.settings"
|
||||
import os
|
||||
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")
|
||||
|
||||
# This application object is used by any WSGI server configured to use this
|
||||
# file. This includes Django's development server, if the WSGI_APPLICATION
|
||||
# setting points here.
|
||||
from django.core.wsgi import get_wsgi_application
|
||||
application = get_wsgi_application()
|
||||
|
||||
# Apply WSGI middleware here.
|
||||
# from helloworld.wsgi import HelloWorldApplication
|
||||
# application = HelloWorldApplication(application)
|
||||
|
|
|
|||
|
|
@ -105,10 +105,15 @@ class TemplateCommand(BaseCommand):
|
|||
base_name = '%s_name' % app_or_project
|
||||
base_subdir = '%s_template' % app_or_project
|
||||
base_directory = '%s_directory' % app_or_project
|
||||
if django.VERSION[-1] == 0:
|
||||
docs_version = 'dev'
|
||||
else:
|
||||
docs_version = '%d.%d' % django.VERSION[:2]
|
||||
|
||||
context = Context(dict(options, **{
|
||||
base_name: name,
|
||||
base_directory: top_dir,
|
||||
'docs_version': docs_version,
|
||||
}), autoescape=False)
|
||||
|
||||
# Setup a stub settings environment for template rendering
|
||||
|
|
|
|||
|
|
@ -438,9 +438,12 @@ def technical_404_response(request, exception):
|
|||
except (IndexError, TypeError, KeyError):
|
||||
tried = []
|
||||
else:
|
||||
if not tried:
|
||||
# tried exists but is an empty list. The URLconf must've been empty.
|
||||
return empty_urlconf(request)
|
||||
if (not tried # empty URLconf
|
||||
or (request.path == '/'
|
||||
and len(tried) == 1 # default URLconf
|
||||
and len(tried[0]) == 1
|
||||
and tried[0][0].app_name == tried[0][0].namespace == 'admin')):
|
||||
return default_urlconf(request)
|
||||
|
||||
urlconf = getattr(request, 'urlconf', settings.ROOT_URLCONF)
|
||||
if isinstance(urlconf, types.ModuleType):
|
||||
|
|
@ -458,12 +461,10 @@ def technical_404_response(request, exception):
|
|||
})
|
||||
return HttpResponseNotFound(t.render(c), content_type='text/html')
|
||||
|
||||
def empty_urlconf(request):
|
||||
def default_urlconf(request):
|
||||
"Create an empty URLconf 404 error response."
|
||||
t = Template(EMPTY_URLCONF_TEMPLATE, name='Empty URLConf template')
|
||||
c = Context({
|
||||
'project_name': settings.SETTINGS_MODULE.split('.')[0]
|
||||
})
|
||||
t = Template(DEFAULT_URLCONF_TEMPLATE, name='Default URLconf template')
|
||||
c = Context({})
|
||||
return HttpResponse(t.render(c), content_type='text/html')
|
||||
|
||||
#
|
||||
|
|
@ -1067,7 +1068,7 @@ TECHNICAL_404_TEMPLATE = """
|
|||
</html>
|
||||
"""
|
||||
|
||||
EMPTY_URLCONF_TEMPLATE = """
|
||||
DEFAULT_URLCONF_TEMPLATE = """
|
||||
<!DOCTYPE html>
|
||||
<html lang="en"><head>
|
||||
<meta http-equiv="content-type" content="text/html; charset=utf-8">
|
||||
|
|
@ -1087,7 +1088,6 @@ EMPTY_URLCONF_TEMPLATE = """
|
|||
tbody td, tbody th { vertical-align:top; padding:2px 3px; }
|
||||
thead th { padding:1px 6px 1px 3px; background:#fefefe; text-align:left; font-weight:normal; font-size:11px; border:1px solid #ddd; }
|
||||
tbody th { width:12em; text-align:right; color:#666; padding-right:.5em; }
|
||||
ul { margin-left: 2em; margin-top: 1em; }
|
||||
#summary { background: #e0ebff; }
|
||||
#summary h2 { font-weight: normal; color: #666; }
|
||||
#explanation { background:#eee; }
|
||||
|
|
@ -1103,11 +1103,10 @@ EMPTY_URLCONF_TEMPLATE = """
|
|||
</div>
|
||||
|
||||
<div id="instructions">
|
||||
<p>Of course, you haven't actually done any work yet. Here's what to do next:</p>
|
||||
<ul>
|
||||
<li>If you plan to use a database, edit the <code>DATABASES</code> setting in <code>{{ project_name }}/settings.py</code>.</li>
|
||||
<li>Start your first app by running <code>python manage.py startapp [appname]</code>.</li>
|
||||
</ul>
|
||||
<p>
|
||||
Of course, you haven't actually done any work yet.
|
||||
Next, start your first app by running <code>python manage.py startapp [appname]</code>.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div id="explanation">
|
||||
|
|
|
|||
|
|
@ -8,9 +8,10 @@ servers and applications.
|
|||
.. _WSGI: http://www.wsgi.org
|
||||
|
||||
Django's :djadmin:`startproject` management command sets up a simple default
|
||||
WSGI configuration for you, which you can tweak as needed for your project, and
|
||||
direct any WSGI-compliant webserver to use. Django includes getting-started
|
||||
documentation for the following WSGI servers:
|
||||
WSGI configuration for you, which you can tweak as needed for your project,
|
||||
and direct any WSGI-compliant application server to use.
|
||||
|
||||
Django includes getting-started documentation for the following WSGI servers:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
|
@ -23,32 +24,76 @@ documentation for the following WSGI servers:
|
|||
The ``application`` object
|
||||
--------------------------
|
||||
|
||||
One key concept of deploying with WSGI is to specify a central ``application``
|
||||
callable object which the webserver uses to communicate with your code. This is
|
||||
commonly specified as an object named ``application`` in a Python module
|
||||
accessible to the server.
|
||||
The key concept of deploying with WSGI is the ``application`` callable which
|
||||
the application server uses to communicate with your code. It's commonly
|
||||
provided as an object named ``application`` in a Python module accessible to
|
||||
the server.
|
||||
|
||||
The :djadmin:`startproject` command creates a :file:`projectname/wsgi.py` that
|
||||
contains such an application callable.
|
||||
The :djadmin:`startproject` command creates a file
|
||||
:file:`<project_name>/wsgi.py` that contains such an ``application`` callable.
|
||||
|
||||
It's used both by Django's development server and in production WSGI
|
||||
deployments.
|
||||
|
||||
WSGI servers obtain the path to the ``application`` callable from their
|
||||
configuration. Django's built-in servers, namely the :djadmin:`runserver` and
|
||||
:djadmin:`runfcgi` commands, read it from the :setting:`WSGI_APPLICATION`
|
||||
setting. By default, it's set to ``<project_name>.wsgi.application``, which
|
||||
points to the ``application`` callable in :file:`<project_name>/wsgi.py`.
|
||||
|
||||
Configuring the settings module
|
||||
-------------------------------
|
||||
|
||||
When the WSGI server loads your application, Django needs to import the
|
||||
settings module — that's where your entire application is defined.
|
||||
|
||||
Django uses the :envvar:`DJANGO_SETTINGS_MODULE` environment variable to
|
||||
locate the appropriate settings module. It must contain the dotted path to the
|
||||
settings module. You can use a different value for development and production;
|
||||
it all depends on how you organize your settings.
|
||||
|
||||
If this variable isn't set, the default :file:`wsgi.py` sets it to
|
||||
``mysite.settings``, where ``mysite`` is the name of your project. That's how
|
||||
:djadmin:`runserver` discovers the default settings file by default.
|
||||
|
||||
.. note::
|
||||
|
||||
Upgrading from a previous release of Django and don't have a :file:`wsgi.py`
|
||||
file in your project? You can simply add one to your project's top-level
|
||||
Python package (probably next to :file:`settings.py` and :file:`urls.py`)
|
||||
with the contents below. If you want :djadmin:`runserver` to also make use
|
||||
of this WSGI file, you can also add ``WSGI_APPLICATION =
|
||||
"mysite.wsgi.application"`` in your settings (replacing ``mysite`` with the
|
||||
name of your project).
|
||||
Since environment variables are process-wide, this doesn't work when you
|
||||
run multiple Django sites in the same process. This happens with mod_wsgi.
|
||||
|
||||
Initially this file contains::
|
||||
To avoid this problem, use mod_wsgi's daemon mode with each site in its
|
||||
own daemon process, or override the value from the environnemnt by
|
||||
enforcing ``os.environ["DJANGO_SETTINGS_MODULE"] = "mysite.settings"`` in
|
||||
your :file:`wsgi.py`.
|
||||
|
||||
|
||||
Applying WSGI middleware
|
||||
------------------------
|
||||
|
||||
To apply `WSGI middleware`_ you can simply wrap the application object. For
|
||||
istance you could add these lines at the bottom of :file:`wsgi.py`::
|
||||
|
||||
from helloworld.wsgi import HelloWorldApplication
|
||||
application = HelloWorldApplication(application)
|
||||
|
||||
You could also replace the Django WSGI application with a custom WSGI
|
||||
application that later delegates to the Django WSGI application, if you want
|
||||
to combine a Django application with a WSGI application of another framework.
|
||||
|
||||
.. _`WSGI middleware`: http://www.python.org/dev/peps/pep-3333/#middleware-components-that-play-both-sides
|
||||
|
||||
Upgrading from Django < 1.4
|
||||
---------------------------
|
||||
|
||||
If you're upgrading from Django 1.3.x or earlier, you don't have a
|
||||
:file:`wsgi.py` file in your project.
|
||||
|
||||
You can simply add one to your project's top-level Python package (probably
|
||||
next to :file:`settings.py` and :file:`urls.py`) with the contents below::
|
||||
|
||||
import os
|
||||
|
||||
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings")
|
||||
|
||||
# This application object is used by the development server
|
||||
# as well as any WSGI server configured to use this file.
|
||||
from django.core.wsgi import get_wsgi_application
|
||||
application = get_wsgi_application()
|
||||
|
||||
|
|
@ -58,14 +103,6 @@ environment variable. You'll need to edit this line to replace ``mysite`` with
|
|||
the name of your project package, so the path to your settings module is
|
||||
correct.
|
||||
|
||||
To apply `WSGI middleware`_ you can simply wrap the application object
|
||||
in the same file::
|
||||
|
||||
from helloworld.wsgi import HelloWorldApplication
|
||||
application = HelloWorldApplication(application)
|
||||
|
||||
You could also replace the Django WSGI application with a custom WSGI
|
||||
application that later delegates to the Django WSGI application, if you want to
|
||||
combine a Django application with a WSGI application of another framework.
|
||||
|
||||
.. _`WSGI middleware`: http://www.python.org/dev/peps/pep-3333/#middleware-components-that-play-both-sides
|
||||
Also add ``WSGI_APPLICATION = "mysite.wsgi.application"`` in your settings, so
|
||||
that :djadmin:`runserver` finds your ``application`` callable. Don't forget to
|
||||
replace ``mysite`` with the name of your project in this line.
|
||||
|
|
|
|||
|
|
@ -39,8 +39,8 @@ By default, Django will send email from root@localhost. However, some mail
|
|||
providers reject all email from this address. To use a different sender
|
||||
address, modify the :setting:`SERVER_EMAIL` setting.
|
||||
|
||||
To disable this behavior, just remove all entries from the :setting:`ADMINS`
|
||||
setting.
|
||||
To activate this behavior, put the email addresses of the recipients in the
|
||||
:setting:`ADMINS` setting.
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 63 KiB After Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 74 KiB After Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB After Width: | Height: | Size: 19 KiB |
|
|
@ -63,8 +63,8 @@ After the previous tutorials, our project should look like this::
|
|||
urls.py
|
||||
wsgi.py
|
||||
polls/
|
||||
admin.py
|
||||
__init__.py
|
||||
admin.py
|
||||
models.py
|
||||
tests.py
|
||||
urls.py
|
||||
|
|
|
|||
|
|
@ -182,40 +182,40 @@ Database setup
|
|||
--------------
|
||||
|
||||
Now, edit :file:`mysite/settings.py`. It's a normal Python module with
|
||||
module-level variables representing Django settings. Change the
|
||||
following keys in the :setting:`DATABASES` ``'default'`` item to match
|
||||
your database connection settings.
|
||||
module-level variables representing Django settings.
|
||||
|
||||
By default, the configuration uses SQLite. If you're new to databases, or
|
||||
you're just interested in trying Django, this is the easiest choice. SQLite is
|
||||
included in Python, so you won't need to install anything else to support your
|
||||
database.
|
||||
|
||||
If you wish to use another database, install the appropriate :ref:`database
|
||||
bindings <database-installation>`, and change the following keys in the
|
||||
:setting:`DATABASES` ``'default'`` item to match your database connection
|
||||
settings:
|
||||
|
||||
* :setting:`ENGINE <DATABASE-ENGINE>` -- Either
|
||||
``'django.db.backends.sqlite3'``,
|
||||
``'django.db.backends.postgresql_psycopg2'``,
|
||||
``'django.db.backends.mysql'``, ``'django.db.backends.sqlite3'`` or
|
||||
``'django.db.backends.mysql'``, or
|
||||
``'django.db.backends.oracle'``. Other backends are :setting:`also available
|
||||
<DATABASE-ENGINE>`.
|
||||
|
||||
* :setting:`NAME` -- The name of your database. If you're using
|
||||
SQLite, the database will be a file on your computer; in that
|
||||
case, :setting:`NAME` should be the full absolute path,
|
||||
including filename, of that file. If the file doesn't exist, it
|
||||
will automatically be created when you synchronize the database
|
||||
for the first time (see below).
|
||||
|
||||
When specifying the path, always use forward slashes, even on
|
||||
Windows (e.g. ``C:/homes/user/mysite/sqlite3.db``).
|
||||
* :setting:`NAME` -- The name of your database. If you're using SQLite, the
|
||||
database will be a file on your computer; in that case, :setting:`NAME`
|
||||
should be the full absolute path, including filename, of that file. When
|
||||
specifying the path, always use forward slashes, even on Windows (e.g.
|
||||
``C:/homes/user/mysite/sqlite3.db``).
|
||||
|
||||
* :setting:`USER` -- Your database username (not used for SQLite).
|
||||
|
||||
* :setting:`PASSWORD` -- Your database password (not used for
|
||||
SQLite).
|
||||
* :setting:`PASSWORD` -- Your database password (not used for SQLite).
|
||||
|
||||
* :setting:`HOST` -- The host your database is on. Leave this as
|
||||
an empty string (or possibly ``127.0.0.1``) if your database server is on the
|
||||
same physical machine (not used for SQLite). See :setting:`HOST` for details.
|
||||
* :setting:`HOST` -- The host your database is on (not used for SQLite).
|
||||
Leave this as an empty string (or possibly ``127.0.0.1``) if your
|
||||
database server is on the same physical machine .
|
||||
|
||||
If you're new to databases, we recommend simply using SQLite by setting
|
||||
:setting:`ENGINE <DATABASE-ENGINE>` to ``'django.db.backends.sqlite3'`` and
|
||||
:setting:`NAME` to the place where you'd like to store the database. SQLite is
|
||||
included in Python, so you won't need to install anything else to support your
|
||||
database.
|
||||
For more details, see the reference documentation for :setting:`DATABASES`.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -226,17 +226,20 @@ database.
|
|||
If you're using SQLite, you don't need to create anything beforehand - the
|
||||
database file will be created automatically when it is needed.
|
||||
|
||||
While you're editing :file:`settings.py`, set :setting:`TIME_ZONE` to your
|
||||
time zone. The default value is the Central time zone in the U.S. (Chicago).
|
||||
While you're editing :file:`mysite/settings.py`, set :setting:`TIME_ZONE` to
|
||||
your time zone.
|
||||
|
||||
Also, note the :setting:`INSTALLED_APPS` setting toward the bottom of
|
||||
the file. That holds the names of all Django applications that are
|
||||
activated in this Django instance. Apps can be used in multiple projects, and
|
||||
you can package and distribute them for use by others in their projects.
|
||||
Also, note the :setting:`INSTALLED_APPS` setting at the top of the file. That
|
||||
holds the names of all Django applications that are activated in this Django
|
||||
instance. Apps can be used in multiple projects, and you can package and
|
||||
distribute them for use by others in their projects.
|
||||
|
||||
By default, :setting:`INSTALLED_APPS` contains the following apps, all of which
|
||||
come with Django:
|
||||
|
||||
* :mod:`django.contrib.admin` -- The admin site. You'll use it in :doc:`part 2
|
||||
of this tutorial </intro/tutorial02>`.
|
||||
|
||||
* :mod:`django.contrib.auth` -- An authentication system.
|
||||
|
||||
* :mod:`django.contrib.contenttypes` -- A framework for content types.
|
||||
|
|
@ -261,11 +264,12 @@ that, run the following command:
|
|||
|
||||
python manage.py syncdb
|
||||
|
||||
The :djadmin:`syncdb` command looks at the :setting:`INSTALLED_APPS` setting and
|
||||
creates any necessary database tables according to the database settings in your
|
||||
:file:`settings.py` file. You'll see a message for each database table it
|
||||
creates, and you'll get a prompt asking you if you'd like to create a superuser
|
||||
account for the authentication system. Go ahead and do that.
|
||||
The :djadmin:`syncdb` command looks at the :setting:`INSTALLED_APPS` setting
|
||||
and creates any necessary database tables according to the database settings
|
||||
in your :file:`mysqlite/settings.py` file. You'll see a message for each
|
||||
database table it creates, and you'll get a prompt asking you if you'd like to
|
||||
create a superuser account for the authentication system. Go ahead and do
|
||||
that.
|
||||
|
||||
If you're interested, run the command-line client for your database and type
|
||||
``\dt`` (PostgreSQL), ``SHOW TABLES;`` (MySQL), or ``.schema`` (SQLite) to
|
||||
|
|
@ -288,10 +292,10 @@ Creating models
|
|||
Now that your environment -- a "project" -- is set up, you're set to start
|
||||
doing work.
|
||||
|
||||
Each application you write in Django consists of a Python package, somewhere
|
||||
on your `Python path`_, that follows a certain convention. Django comes with a
|
||||
utility that automatically generates the basic directory structure of an app,
|
||||
so you can focus on writing code rather than creating directories.
|
||||
Each application you write in Django consists of a Python package that follows
|
||||
a certain convention. Django comes with a utility that automatically generates
|
||||
the basic directory structure of an app, so you can focus on writing code
|
||||
rather than creating directories.
|
||||
|
||||
.. admonition:: Projects vs. apps
|
||||
|
||||
|
|
@ -316,6 +320,7 @@ That'll create a directory :file:`polls`, which is laid out like this::
|
|||
|
||||
polls/
|
||||
__init__.py
|
||||
admin.py
|
||||
models.py
|
||||
tests.py
|
||||
views.py
|
||||
|
|
@ -401,26 +406,21 @@ But first we need to tell our project that the ``polls`` app is installed.
|
|||
you can distribute apps, because they don't have to be tied to a given
|
||||
Django installation.
|
||||
|
||||
Edit the :file:`settings.py` file again, and change the
|
||||
:setting:`INSTALLED_APPS` setting to include the string ``'polls'``. So
|
||||
it'll look like this::
|
||||
Edit the :file:`mysite/settings.py` file again, and change the
|
||||
:setting:`INSTALLED_APPS` setting to include the string ``'polls'``. So it'll
|
||||
look like this::
|
||||
|
||||
INSTALLED_APPS = (
|
||||
'django.contrib.admin',
|
||||
'django.contrib.auth',
|
||||
'django.contrib.contenttypes',
|
||||
'django.contrib.sessions',
|
||||
'django.contrib.sites',
|
||||
'django.contrib.messages',
|
||||
'django.contrib.staticfiles',
|
||||
# Uncomment the next line to enable the admin:
|
||||
# 'django.contrib.admin',
|
||||
# Uncomment the next line to enable admin documentation:
|
||||
# 'django.contrib.admindocs',
|
||||
'polls',
|
||||
)
|
||||
|
||||
Now Django knows to include the ``polls`` app. Let's run another
|
||||
command:
|
||||
Now Django knows to include the ``polls`` app. Let's run another command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
|
@ -433,13 +433,13 @@ statements for the polls app):
|
|||
|
||||
BEGIN;
|
||||
CREATE TABLE "polls_poll" (
|
||||
"id" serial NOT NULL PRIMARY KEY,
|
||||
"id" integer NOT NULL PRIMARY KEY,
|
||||
"question" varchar(200) NOT NULL,
|
||||
"pub_date" timestamp with time zone NOT NULL
|
||||
"pub_date" datetime NOT NULL
|
||||
);
|
||||
CREATE TABLE "polls_choice" (
|
||||
"id" serial NOT NULL PRIMARY KEY,
|
||||
"poll_id" integer NOT NULL REFERENCES "polls_poll" ("id") DEFERRABLE INITIALLY DEFERRED,
|
||||
"id" integer NOT NULL PRIMARY KEY,
|
||||
"poll_id" integer NOT NULL REFERENCES "polls_poll" ("id"),
|
||||
"choice_text" varchar(200) NOT NULL,
|
||||
"votes" integer NOT NULL
|
||||
);
|
||||
|
|
@ -447,7 +447,8 @@ statements for the polls app):
|
|||
|
||||
Note the following:
|
||||
|
||||
* The exact output will vary depending on the database you are using.
|
||||
* The exact output will vary depending on the database you are using. The
|
||||
example above is generated for SQLite.
|
||||
|
||||
* Table names are automatically generated by combining the name of the app
|
||||
(``polls``) and the lowercase name of the model -- ``poll`` and
|
||||
|
|
@ -465,8 +466,7 @@ Note the following:
|
|||
types such as ``auto_increment`` (MySQL), ``serial`` (PostgreSQL), or
|
||||
``integer primary key`` (SQLite) are handled for you automatically. Same
|
||||
goes for quoting of field names -- e.g., using double quotes or single
|
||||
quotes. The author of this tutorial runs PostgreSQL, so the example
|
||||
output is in PostgreSQL syntax.
|
||||
quotes.
|
||||
|
||||
* The :djadmin:`sql` command doesn't actually run the SQL in your database -
|
||||
it just prints it to the screen so that you can see what SQL Django thinks
|
||||
|
|
|
|||
|
|
@ -21,49 +21,11 @@ automatically-generated admin site.
|
|||
The admin isn't intended to be used by site visitors. It's for site
|
||||
managers.
|
||||
|
||||
Activate the admin site
|
||||
=======================
|
||||
|
||||
The Django admin site is not activated by default -- it's an opt-in thing. To
|
||||
activate the admin site for your installation, do these three things:
|
||||
|
||||
* Uncomment ``"django.contrib.admin"`` in the :setting:`INSTALLED_APPS` setting.
|
||||
|
||||
* Run ``python manage.py syncdb``. Since you have added a new application
|
||||
to :setting:`INSTALLED_APPS`, the database tables need to be updated.
|
||||
|
||||
* Edit your ``mysite/urls.py`` file and uncomment the lines that reference
|
||||
the admin -- there are three lines in total to uncomment. This file is a
|
||||
URLconf; we'll dig into URLconfs in the next tutorial. For now, all you
|
||||
need to know is that it maps URL roots to applications. In the end, you
|
||||
should have a ``urls.py`` file that looks like this:
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
from django.conf.urls import patterns, include, url
|
||||
|
||||
# Uncomment the next two lines to enable the admin:
|
||||
**from django.contrib import admin**
|
||||
**admin.autodiscover()**
|
||||
|
||||
urlpatterns = patterns('',
|
||||
# Examples:
|
||||
# url(r'^$', '{{ project_name }}.views.home', name='home'),
|
||||
# url(r'^{{ project_name }}/', include('{{ project_name }}.foo.urls')),
|
||||
|
||||
# Uncomment the admin/doc line below to enable admin documentation:
|
||||
# url(r'^admin/doc/', include('django.contrib.admindocs.urls')),
|
||||
|
||||
# Uncomment the next line to enable the admin:
|
||||
**url(r'^admin/', include(admin.site.urls)),**
|
||||
)
|
||||
|
||||
(The bold lines are the ones that needed to be uncommented.)
|
||||
|
||||
Start the development server
|
||||
============================
|
||||
|
||||
Let's start the development server and explore the admin site.
|
||||
The Django admin site is activated by default. Let's start the development
|
||||
server and explore it.
|
||||
|
||||
Recall from Tutorial 1 that you start the development server like so:
|
||||
|
||||
|
|
@ -77,6 +39,10 @@ http://127.0.0.1:8000/admin/. You should see the admin's login screen:
|
|||
.. image:: _images/admin01.png
|
||||
:alt: Django admin login screen
|
||||
|
||||
Since :doc:`translation </topics/i18n/translation>` is turned on by default,
|
||||
the login screen may be displayed in your own language, depending on your
|
||||
browser's settings and on whether Django has a translation for this language.
|
||||
|
||||
.. admonition:: Doesn't match what you see?
|
||||
|
||||
If at this point, instead of the above login page, you get an error
|
||||
|
|
@ -93,24 +59,26 @@ http://127.0.0.1:8000/admin/. You should see the admin's login screen:
|
|||
Enter the admin site
|
||||
====================
|
||||
|
||||
Now, try logging in. (You created a superuser account in the first part of this
|
||||
Now, try logging in. You created a superuser account in the first part of this
|
||||
tutorial, remember? If you didn't create one or forgot the password you can
|
||||
:ref:`create another one <topics-auth-creating-superusers>`.) You should see
|
||||
the Django admin index page:
|
||||
:ref:`create another one <topics-auth-creating-superusers>`.
|
||||
|
||||
You should see the Django admin index page:
|
||||
|
||||
.. image:: _images/admin02t.png
|
||||
:alt: Django admin index page
|
||||
|
||||
You should see a few types of editable content, including groups, users
|
||||
and sites. These are core features Django ships with by default.
|
||||
You should see a few types of editable content: groups and users. They are
|
||||
provided by :mod:`django.contrib.auth`, the authentication framework shipped
|
||||
by Django.
|
||||
|
||||
Make the poll app modifiable in the admin
|
||||
=========================================
|
||||
|
||||
But where's our poll app? It's not displayed on the admin index page.
|
||||
|
||||
Just one thing to do: We need to tell the admin that ``Poll``
|
||||
objects have an admin interface. To do this, create a file called
|
||||
Just one thing to do: we need to tell the admin that ``Poll``
|
||||
objects have an admin interface. To do this, open the file called
|
||||
``admin.py`` in your ``polls`` directory, and edit it to look like this::
|
||||
|
||||
from django.contrib import admin
|
||||
|
|
@ -118,10 +86,6 @@ objects have an admin interface. To do this, create a file called
|
|||
|
||||
admin.site.register(Poll)
|
||||
|
||||
You'll need to restart the development server to see your changes. Normally,
|
||||
the server auto-reloads code every time you modify a file, but the action of
|
||||
creating a new file doesn't trigger the auto-reloading logic.
|
||||
|
||||
Explore the free admin functionality
|
||||
====================================
|
||||
|
||||
|
|
@ -145,7 +109,7 @@ Click the "What's up?" poll to edit it:
|
|||
|
||||
Things to note here:
|
||||
|
||||
* The form is automatically generated from the Poll model.
|
||||
* The form is automatically generated from the ``Poll`` model.
|
||||
|
||||
* The different model field types (:class:`~django.db.models.DateTimeField`,
|
||||
:class:`~django.db.models.CharField`) correspond to the appropriate HTML
|
||||
|
|
@ -302,7 +266,7 @@ registration code to read::
|
|||
This tells Django: "``Choice`` objects are edited on the ``Poll`` admin page. By
|
||||
default, provide enough fields for 3 choices."
|
||||
|
||||
Load the "Add poll" page to see how that looks, you may need to restart your development server:
|
||||
Load the "Add poll" page to see how that looks:
|
||||
|
||||
.. image:: _images/admin11t.png
|
||||
:alt: Add poll page now has choices on it
|
||||
|
|
@ -435,31 +399,24 @@ That's easy to change, though, using Django's template system. The Django admin
|
|||
is powered by Django itself, and its interfaces use Django's own template
|
||||
system.
|
||||
|
||||
Open your settings file (``mysite/settings.py``, remember) and look at the
|
||||
:setting:`TEMPLATE_DIRS` setting. :setting:`TEMPLATE_DIRS` is a tuple of
|
||||
filesystem directories to check when loading Django templates. It's a search
|
||||
path.
|
||||
|
||||
Create a ``mytemplates`` directory in your project directory. Templates can
|
||||
live anywhere on your filesystem that Django can access. (Django runs as
|
||||
whatever user your server runs.) However, keeping your templates within the
|
||||
project is a good convention to follow.
|
||||
|
||||
By default, :setting:`TEMPLATE_DIRS` is empty. So, let's add a line to it, to
|
||||
tell Django where our templates live::
|
||||
Open your settings file (``mysite/settings.py``, remember) and add a
|
||||
:setting:`TEMPLATE_DIRS` setting::
|
||||
|
||||
TEMPLATE_DIRS = (
|
||||
'/path/to/mysite/mytemplates', # Change this to your own directory.
|
||||
)
|
||||
TEMPLATE_DIRS = (os.path.join(BASE_DIR, 'mytemplates'),)
|
||||
|
||||
Now copy the template ``admin/base_site.html`` from within the default Django
|
||||
admin template directory in the source code of Django itself
|
||||
(``django/contrib/admin/templates``) into an ``admin`` subdirectory of
|
||||
whichever directory you're using in :setting:`TEMPLATE_DIRS`. For example, if
|
||||
your :setting:`TEMPLATE_DIRS` includes ``'/path/to/mysite/mytemplates'``, as
|
||||
above, then copy ``django/contrib/admin/templates/admin/base_site.html`` to
|
||||
``/path/to/mysite/mytemplates/admin/base_site.html``. Don't forget that
|
||||
``admin`` subdirectory.
|
||||
Don't forget the trailing comma. :setting:`TEMPLATE_DIRS` is a tuple of
|
||||
filesystem directories to check when loading Django templates; it's a search
|
||||
path.
|
||||
|
||||
Now create a directory called ``admin`` inside ``mytemplates``, and copy the
|
||||
template ``admin/base_site.html`` from within the default Django admin
|
||||
template directory in the source code of Django itself
|
||||
(``django/contrib/admin/templates``) into that directory.
|
||||
|
||||
.. admonition:: Where are the Django source files?
|
||||
|
||||
|
|
|
|||
|
|
@ -159,8 +159,7 @@ can do in an automated test, so let's turn that into an automated test.
|
|||
The best place for an application's tests is in the application's ``tests.py``
|
||||
file - the testing system will look there for tests automatically.
|
||||
|
||||
Put the following in the ``tests.py`` file in the ``polls`` application (you'll
|
||||
notice ``tests.py`` contains some dummy tests, you can remove those)::
|
||||
Put the following in the ``tests.py`` file in the ``polls`` application::
|
||||
|
||||
import datetime
|
||||
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ How to use it
|
|||
Setting X-Frame-Options for all responses
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To set the same X-Frame-Options value for all responses in your site, add
|
||||
To set the same X-Frame-Options value for all responses in your site, put
|
||||
``'django.middleware.clickjacking.XFrameOptionsMiddleware'`` to
|
||||
:setting:`MIDDLEWARE_CLASSES`::
|
||||
|
||||
|
|
@ -61,6 +61,10 @@ To set the same X-Frame-Options value for all responses in your site, add
|
|||
...
|
||||
)
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
This middleware is enabled in the settings file generated by
|
||||
:djadmin:`startproject`.
|
||||
|
||||
By default, the middleware will set the X-Frame-Options header to SAMEORIGIN for
|
||||
every outgoing ``HttpResponse``. If you want DENY instead, set the
|
||||
:setting:`X_FRAME_OPTIONS` setting::
|
||||
|
|
|
|||
|
|
@ -14,7 +14,13 @@ Django's admin interface.
|
|||
Overview
|
||||
========
|
||||
|
||||
There are seven steps in activating the Django admin site:
|
||||
The admin is enabled in the default project template used by
|
||||
:djadmin:`startproject`.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
In previous versions, the admin wasn't enabled by default.
|
||||
|
||||
For reference, here are the requirements:
|
||||
|
||||
1. Add ``'django.contrib.admin'`` to your :setting:`INSTALLED_APPS`
|
||||
setting.
|
||||
|
|
|
|||
|
|
@ -115,13 +115,12 @@ In addition, modify the :setting:`INSTALLED_APPS` setting to include
|
|||
and ``world`` (your newly created application)::
|
||||
|
||||
INSTALLED_APPS = (
|
||||
'django.contrib.admin',
|
||||
'django.contrib.auth',
|
||||
'django.contrib.contenttypes',
|
||||
'django.contrib.sessions',
|
||||
'django.contrib.sites',
|
||||
'django.contrib.messages',
|
||||
'django.contrib.staticfiles',
|
||||
'django.contrib.admin',
|
||||
'django.contrib.gis',
|
||||
'world'
|
||||
)
|
||||
|
|
|
|||
|
|
@ -247,13 +247,29 @@ To do this, you can use the sites framework. A simple example::
|
|||
'http://example.com/mymodel/objects/3/'
|
||||
|
||||
|
||||
Default site and ``syncdb``
|
||||
===========================
|
||||
Enabling the sites framework
|
||||
============================
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
In previous versions, the sites framework was enabled by default.
|
||||
|
||||
To enable the sites framework, follow these steps:
|
||||
|
||||
1. Add ``'django.contrib.sites'`` to your :setting:`INSTALLED_APPS`
|
||||
setting.
|
||||
|
||||
2. Define a :setting:`SITE_ID` setting::
|
||||
|
||||
SITE_ID = 1
|
||||
|
||||
3. Run :djadmin:`syncdb`.
|
||||
|
||||
``django.contrib.sites`` registers a
|
||||
:data:`~django.db.models.signals.post_syncdb` signal handler which creates a
|
||||
default site named ``example.com`` with the domain ``example.com``. For
|
||||
example, this site will be created after Django creates the test database.
|
||||
default site named ``example.com`` with the domain ``example.com``. This site
|
||||
will also be created after Django creates the test database. To set the
|
||||
correct name and domain for your project, you can use an :doc:`initial data
|
||||
fixture </howto/initial-data>`.
|
||||
|
||||
Caching the current ``Site`` object
|
||||
===================================
|
||||
|
|
|
|||
|
|
@ -921,6 +921,8 @@ For example::
|
|||
|
||||
django-admin.py startapp myapp /Users/jezdez/Code/myapp
|
||||
|
||||
.. _custom-app-and-project-templates:
|
||||
|
||||
.. django-admin-option:: --template
|
||||
|
||||
With the ``--template`` option, you can use a custom app template by providing
|
||||
|
|
@ -952,6 +954,7 @@ with the ``--name`` option. The :class:`template context
|
|||
options)
|
||||
- ``app_name`` -- the app name as passed to the command
|
||||
- ``app_directory`` -- the full path of the newly created app
|
||||
- ``docs_version`` -- the version of the documentation: ``'dev'`` or ``'1.x'``
|
||||
|
||||
.. _render_warning:
|
||||
|
||||
|
|
@ -1021,6 +1024,7 @@ with the ``--name`` option. The :class:`template context
|
|||
- ``project_name`` -- the project name as passed to the command
|
||||
- ``project_directory`` -- the full path of the newly created project
|
||||
- ``secret_key`` -- a random key for the :setting:`SECRET_KEY` setting
|
||||
- ``docs_version`` -- the version of the documentation: ``'dev'`` or ``'1.x'``
|
||||
|
||||
Please also see the :ref:`rendering warning <render_warning>` as mentioned
|
||||
for :djadmin:`startapp`.
|
||||
|
|
|
|||
|
|
@ -1134,9 +1134,12 @@ LANGUAGE_CODE
|
|||
|
||||
Default: ``'en-us'``
|
||||
|
||||
A string representing the language code for this installation. This should be in
|
||||
standard :term:`language format<language code>`. For example, U.S. English is
|
||||
``"en-us"``. See :doc:`/topics/i18n/index`.
|
||||
A string representing the language code for this installation. This should be
|
||||
in standard :term:`language format<language code>`. For example, U.S. English
|
||||
is ``"en-us"``. See also the `list of language identifiers`_ and
|
||||
:doc:`/topics/i18n/index`.
|
||||
|
||||
.. _list of language identifiers: http://www.i18nguy.com/unicode/language-identifiers.html
|
||||
|
||||
.. setting:: LANGUAGE_COOKIE_NAME
|
||||
|
||||
|
|
@ -1668,12 +1671,8 @@ TIME_ZONE
|
|||
|
||||
Default: ``'America/Chicago'``
|
||||
|
||||
A string representing the time zone for this installation, or
|
||||
``None``. `See available choices`_. (Note that list of available
|
||||
choices lists more than one on the same line; you'll want to use just
|
||||
one of the choices for a given time zone. For instance, one line says
|
||||
``'Europe/London GB GB-Eire'``, but you should use the first bit of
|
||||
that -- ``'Europe/London'`` -- as your :setting:`TIME_ZONE` setting.)
|
||||
A string representing the time zone for this installation, or ``None``. See
|
||||
the `list of time zones`_.
|
||||
|
||||
Note that this isn't necessarily the time zone of the server. For example, one
|
||||
server may serve multiple Django-powered sites, each with a separate time zone
|
||||
|
|
@ -1706,7 +1705,7 @@ to ensure your processes are running in the correct environment.
|
|||
If you're running Django on Windows, :setting:`TIME_ZONE` must be set to
|
||||
match the system time zone.
|
||||
|
||||
.. _See available choices: http://www.postgresql.org/docs/8.1/static/datetime-keywords.html#DATETIME-TIMEZONE-SET-TABLE
|
||||
.. _list of time zones: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
|
||||
|
||||
.. _pytz: http://pytz.sourceforge.net/
|
||||
|
||||
|
|
|
|||
|
|
@ -17,6 +17,19 @@ deprecation process for some features`_.
|
|||
What's new in Django 1.6
|
||||
========================
|
||||
|
||||
Simplified default project and app templates
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The default templates used by :djadmin:`startproject` and :djadmin:`startapp`
|
||||
have been simplified and modernized. The :doc:`admin
|
||||
</ref/contrib/admin/index>` is now enabled by default in new projects; the
|
||||
:doc:`sites </ref/contrib/sites>` framework no longer is. :ref:`Language
|
||||
detection <how-django-discovers-language-preference>` and :ref:`clickjacking
|
||||
prevention <clickjacking-prevention>` are turned on.
|
||||
|
||||
If the default templates don't suit your tastes, you can use :ref:`custom
|
||||
project and app templates <custom-app-and-project-templates>`.
|
||||
|
||||
Minor features
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,9 @@ use internationalization, you should take the two seconds to set
|
|||
:setting:`USE_I18N = False <USE_I18N>` in your settings file. Then Django will
|
||||
make some optimizations so as not to load the internationalization machinery.
|
||||
You'll probably also want to remove ``'django.core.context_processors.i18n'``
|
||||
from your :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting.
|
||||
from your :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting and
|
||||
``'django.middleware.locale.LocaleMiddleware'`` from your
|
||||
:setting:`MIDDLEWARE_CLASSES` setting.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -1476,9 +1478,14 @@ If you want to let each individual user specify which language he or she
|
|||
prefers, use ``LocaleMiddleware``. ``LocaleMiddleware`` enables language
|
||||
selection based on data from the request. It customizes content for each user.
|
||||
|
||||
To use ``LocaleMiddleware``, add ``'django.middleware.locale.LocaleMiddleware'``
|
||||
to your :setting:`MIDDLEWARE_CLASSES` setting. Because middleware order
|
||||
matters, you should follow these guidelines:
|
||||
``LocaleMiddleware`` is enabled in the default settings file: the
|
||||
:setting:`MIDDLEWARE_CLASSES` setting contains
|
||||
``'django.middleware.locale.LocaleMiddleware'``.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
In previous versions, ``LocaleMiddleware` wasn't enabled by default.
|
||||
|
||||
Because middleware order matters, you should follow these guidelines:
|
||||
|
||||
* Make sure it's one of the first middlewares installed.
|
||||
* It should come after ``SessionMiddleware``, because ``LocaleMiddleware``
|
||||
|
|
|
|||
Loading…
Reference in New Issue