Fixed #11272 -- Made some clarifications to the overview and tutorial. Thanks to jjinux for the review notes.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11044 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
bc362cc6b8
commit
457a1f9a03
|
@ -144,10 +144,10 @@ as registering your model in the admin site::
|
|||
headline = models.CharField(max_length=200)
|
||||
content = models.TextField()
|
||||
reporter = models.ForeignKey(Reporter)
|
||||
|
||||
|
||||
|
||||
# In admin.py in the same directory...
|
||||
|
||||
|
||||
import models
|
||||
from django.contrib import admin
|
||||
|
||||
|
@ -243,9 +243,9 @@ might look like:
|
|||
<h1>Articles for {{ year }}</h1>
|
||||
|
||||
{% for article in article_list %}
|
||||
<p>{{ article.headline }}</p>
|
||||
<p>By {{ article.reporter.full_name }}</p>
|
||||
<p>Published {{ article.pub_date|date:"F j, Y" }}</p>
|
||||
<p>{{ article.headline }}</p>
|
||||
<p>By {{ article.reporter.full_name }}</p>
|
||||
<p>Published {{ article.pub_date|date:"F j, Y" }}</p>
|
||||
{% endfor %}
|
||||
{% endblock %}
|
||||
|
||||
|
|
|
@ -42,13 +42,13 @@ code, then run the command ``django-admin.py startproject mysite``. This will
|
|||
create a ``mysite`` directory in your current directory.
|
||||
|
||||
.. admonition:: Mac OS X permissions
|
||||
|
||||
|
||||
If you're using Mac OS X, you may see the message "permission denied" when
|
||||
you try to run ``django-admin.py startproject``. This is because, on
|
||||
Unix-based systems like OS X, a file must be marked as "executable" before it
|
||||
can be run as a program. To do this, open Terminal.app and navigate (using
|
||||
the ``cd`` command) to the directory where :ref:`django-admin.py
|
||||
<ref-django-admin>` is installed, then run the command
|
||||
<ref-django-admin>` is installed, then run the command
|
||||
``chmod +x django-admin.py``.
|
||||
|
||||
.. note::
|
||||
|
@ -90,14 +90,14 @@ These files are:
|
|||
* :file:`__init__.py`: An empty file that tells Python that this directory
|
||||
should be considered a Python package. (Read `more about packages`_ in the
|
||||
official Python docs if you're a Python beginner.)
|
||||
|
||||
|
||||
* :file:`manage.py`: A command-line utility that lets you interact with this
|
||||
Django project in various ways. You can read all the details about
|
||||
:file:`manage.py` in :ref:`ref-django-admin`.
|
||||
|
||||
|
||||
* :file:`settings.py`: Settings/configuration for this Django project.
|
||||
:ref:`topics-settings` will tell you all about how settings work.
|
||||
|
||||
|
||||
* :file:`urls.py`: The URL declarations for this Django project; a "table of
|
||||
contents" of your Django-powered site. You can read more about URLs in
|
||||
:ref:`topics-http-urls`.
|
||||
|
@ -134,22 +134,22 @@ It worked!
|
|||
.. admonition:: Changing the port
|
||||
|
||||
By default, the :djadmin:`runserver` command starts the development server
|
||||
on the internal IP at port 8000.
|
||||
|
||||
on the internal IP at port 8000.
|
||||
|
||||
If you want to change the server's port, pass
|
||||
it as a command-line argument. For instance, this command starts the server
|
||||
on port 8080:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
python manage.py runserver 8080
|
||||
|
||||
|
||||
If you want to change the server's IP, pass it along with the port. So to
|
||||
listen on all public IPs (useful if you want to show off your work on other
|
||||
computers), use:
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
||||
python manage.py runserver 0.0.0.0:8000
|
||||
|
||||
Full docs for the development server can be found in the
|
||||
|
@ -164,21 +164,21 @@ database's connection parameters:
|
|||
|
||||
* :setting:`DATABASE_ENGINE` -- Either 'postgresql_psycopg2', 'mysql' or
|
||||
'sqlite3'. Other backends are :setting:`also available <DATABASE_ENGINE>`.
|
||||
|
||||
|
||||
* :setting:`DATABASE_NAME` -- The name of your database. If you're using
|
||||
SQLite, the database will be a file on your computer; in that case,
|
||||
``DATABASE_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
|
||||
|
||||
When specifying the path, always use forward slashes, even on Windows
|
||||
(e.g. ``C:/homes/user/mysite/sqlite3.db``).
|
||||
|
||||
|
||||
* :setting:`DATABASE_USER` -- Your database username (not used for SQLite).
|
||||
|
||||
|
||||
* :setting:`DATABASE_PASSWORD` -- Your database password (not used for
|
||||
SQLite).
|
||||
|
||||
|
||||
* :setting:`DATABASE_HOST` -- The host your database is on. Leave this as an
|
||||
empty string if your database server is on the same physical machine (not
|
||||
used for SQLite).
|
||||
|
@ -594,7 +594,7 @@ your models, not only for your own sanity when dealing with the interactive
|
|||
prompt, but also because objects' representations are used throughout Django's
|
||||
automatically-generated admin.
|
||||
|
||||
.. admonition:: Why :meth:`~django.db.models.Model.__unicode__` and not
|
||||
.. admonition:: Why :meth:`~django.db.models.Model.__unicode__` and not
|
||||
:meth:`~django.db.models.Model.__str__`?
|
||||
|
||||
If you're familiar with Python, you might be in the habit of adding
|
||||
|
|
|
@ -86,8 +86,8 @@ Enter the admin site
|
|||
====================
|
||||
|
||||
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
|
||||
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:
|
||||
|
||||
.. image:: _images/admin02t.png
|
||||
|
@ -238,8 +238,8 @@ the admin page doesn't display choices.
|
|||
|
||||
Yet.
|
||||
|
||||
There are two ways to solve this problem. The first register ``Choice`` with the
|
||||
admin just as we did with ``Poll``. That's easy::
|
||||
There are two ways to solve this problem. The first is to register ``Choice``
|
||||
with the admin just as we did with ``Poll``. That's easy::
|
||||
|
||||
from mysite.polls.models import Choice
|
||||
|
||||
|
|
|
@ -71,7 +71,7 @@ For more on :class:`~django.http.HttpRequest` objects, see the
|
|||
:ref:`ref-request-response`. For more details on URLconfs, see the
|
||||
:ref:`topics-http-urls`.
|
||||
|
||||
When you ran ``python django-admin.py startproject mysite`` at the beginning of
|
||||
When you ran ``django-admin.py startproject mysite`` at the beginning of
|
||||
Tutorial 1, it created a default URLconf in ``mysite/urls.py``. It also
|
||||
automatically set your :setting:`ROOT_URLCONF` setting (in ``settings.py``) to
|
||||
point at that file::
|
||||
|
@ -98,8 +98,7 @@ This is worth a review. When somebody requests a page from your Web site -- say,
|
|||
the :setting:`ROOT_URLCONF` setting. It finds the variable named ``urlpatterns``
|
||||
and traverses the regular expressions in order. When it finds a regular
|
||||
expression that matches -- ``r'^polls/(?P<poll_id>\d+)/$'`` -- it loads the
|
||||
associated Python package/module: ``mysite.polls.views.detail``. That
|
||||
corresponds to the function ``detail()`` in ``mysite/polls/views.py``. Finally,
|
||||
function ``detail()`` from ``mysite/polls/views.py``. Finally,
|
||||
it calls that ``detail()`` function like so::
|
||||
|
||||
detail(request=<HttpRequest object>, poll_id='23')
|
||||
|
@ -486,7 +485,8 @@ Here's what happens if a user goes to "/polls/34/" in this system:
|
|||
further processing.
|
||||
|
||||
Now that we've decoupled that, we need to decouple the 'mysite.polls.urls'
|
||||
URLconf by removing the leading "polls/" from each line::
|
||||
URLconf by removing the leading "polls/" from each line, and removing the
|
||||
lines registering the admin site::
|
||||
|
||||
urlpatterns = patterns('mysite.polls.views',
|
||||
(r'^$', 'index'),
|
||||
|
|
|
@ -347,8 +347,8 @@ doesn't work with a
|
|||
:class:`~django.contrib.contenttypes.generic.GenericRelation`. For example, you
|
||||
might be tempted to try something like::
|
||||
|
||||
Bookmark.objects.aggregate(Count('tags'))
|
||||
|
||||
Bookmark.objects.aggregate(Count('tags'))
|
||||
|
||||
This will not work correctly, however. The generic relation adds extra filters
|
||||
to the queryset to ensure the correct content type, but the ``aggregate`` method
|
||||
doesn't take them into account. For now, if you need aggregates on generic
|
||||
|
|
|
@ -4,6 +4,9 @@
|
|||
How to use sessions
|
||||
===================
|
||||
|
||||
.. module:: django.contrib.sessions
|
||||
:synopsis: Provides session management for Django projects.
|
||||
|
||||
Django provides full support for anonymous sessions. The session framework lets
|
||||
you store and retrieve arbitrary data on a per-site-visitor basis. It stores
|
||||
data on the server side and abstracts the sending and receiving of cookies.
|
||||
|
|
Loading…
Reference in New Issue