mirror of
https://github.com/django/django.git
synced 2025-10-23 21:59:11 +00:00
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
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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user