[1.2.X] Fixed #11509 -- Modified usage of "Web" to match our style guide in various documentation, comments and code. Thanks to timo and Simon Meers for the work on the patch
Backport of r14069 from trunk. git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.2.X@14072 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
a322ba66a1
commit
9584b77c35
|
@ -19,7 +19,7 @@ class AuthenticationMiddleware(object):
|
|||
|
||||
class RemoteUserMiddleware(object):
|
||||
"""
|
||||
Middleware for utilizing web-server-provided authentication.
|
||||
Middleware for utilizing Web-server-provided authentication.
|
||||
|
||||
If request.user is not authenticated, then this middleware attempts to
|
||||
authenticate the username passed in the ``REMOTE_USER`` request header.
|
||||
|
|
|
@ -16,7 +16,7 @@ Example
|
|||
-------
|
||||
|
||||
First, we define a simple model class which might represent entries in
|
||||
a weblog::
|
||||
a Weblog::
|
||||
|
||||
from django.db import models
|
||||
|
||||
|
|
|
@ -37,7 +37,7 @@ from django.contrib.gis.gdal.prototypes import srs as capi
|
|||
#### Spatial Reference class. ####
|
||||
class SpatialReference(GDALBase):
|
||||
"""
|
||||
A wrapper for the OGRSpatialReference object. According to the GDAL website,
|
||||
A wrapper for the OGRSpatialReference object. According to the GDAL Web site,
|
||||
the SpatialReference object "provide[s] services to represent coordinate
|
||||
systems (projections and datums) and to transform between them."
|
||||
"""
|
||||
|
|
|
@ -2,7 +2,7 @@ import re
|
|||
|
||||
# Regular expression for recognizing HEXEWKB and WKT. A prophylactic measure
|
||||
# to prevent potentially malicious input from reaching the underlying C
|
||||
# library. Not a substitute for good web security programming practices.
|
||||
# library. Not a substitute for good Web security programming practices.
|
||||
hex_regex = re.compile(r'^[0-9A-F]+$', re.I)
|
||||
wkt_regex = re.compile(r'^(SRID=(?P<srid>\d+);)?'
|
||||
r'(?P<wkt>'
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
"""
|
||||
This module houses the GoogleMap object, used for generating
|
||||
the needed javascript to embed Google Maps in a webpage.
|
||||
the needed javascript to embed Google Maps in a Web page.
|
||||
|
||||
Google(R) is a registered trademark of Google, Inc. of Mountain View, California.
|
||||
|
||||
|
|
|
@ -40,7 +40,7 @@ class Session(models.Model):
|
|||
|
||||
For complete documentation on using Sessions in your code, consult
|
||||
the sessions documentation that is shipped with Django (also available
|
||||
on the Django website).
|
||||
on the Django Web site).
|
||||
"""
|
||||
session_key = models.CharField(_('session key'), max_length=40,
|
||||
primary_key=True)
|
||||
|
|
|
@ -116,7 +116,7 @@ class Storage(object):
|
|||
def url(self, name):
|
||||
"""
|
||||
Returns an absolute URL where the file's contents can be accessed
|
||||
directly by a web browser.
|
||||
directly by a Web browser.
|
||||
"""
|
||||
raise NotImplementedError()
|
||||
|
||||
|
|
|
@ -208,7 +208,7 @@ def get_script_name(environ):
|
|||
|
||||
# If Apache's mod_rewrite had a whack at the URL, Apache set either
|
||||
# SCRIPT_URL or REDIRECT_URL to the full resource URL before applying any
|
||||
# rewrites. Unfortunately not every webserver (lighttpd!) passes this
|
||||
# rewrites. Unfortunately not every Web server (lighttpd!) passes this
|
||||
# information through all the time, so FORCE_SCRIPT_NAME, above, is still
|
||||
# needed.
|
||||
script_url = environ.get('SCRIPT_URL', u'')
|
||||
|
|
|
@ -46,7 +46,7 @@ Optional Fcgi settings: (setting=value)
|
|||
|
||||
Examples:
|
||||
Run a "standard" fastcgi process on a file-descriptor
|
||||
(for webservers which spawn your processes for you)
|
||||
(for Web servers which spawn your processes for you)
|
||||
$ manage.py runfcgi method=threaded
|
||||
|
||||
Run a scgi server on a TCP host/port
|
||||
|
|
|
@ -514,7 +514,7 @@ class BooleanField(Field):
|
|||
raise exceptions.ValidationError(self.error_messages['invalid'])
|
||||
|
||||
def get_prep_lookup(self, lookup_type, value):
|
||||
# Special-case handling for filters coming from a web request (e.g. the
|
||||
# Special-case handling for filters coming from a Web request (e.g. the
|
||||
# admin interface). Only works for scalar values (not lists). If you're
|
||||
# passing in a list, you might as well make things the right type when
|
||||
# constructing the list.
|
||||
|
@ -954,7 +954,7 @@ class NullBooleanField(Field):
|
|||
raise exceptions.ValidationError(self.error_messages['invalid'])
|
||||
|
||||
def get_prep_lookup(self, lookup_type, value):
|
||||
# Special-case handling for filters coming from a web request (e.g. the
|
||||
# Special-case handling for filters coming from a Web request (e.g. the
|
||||
# admin interface). Only works for scalar values (not lists). If you're
|
||||
# passing in a list, you might as well make things the right type when
|
||||
# constructing the list.
|
||||
|
|
|
@ -288,7 +288,7 @@ def commit_on_success(using=None):
|
|||
This decorator activates commit on response. This way, if the view function
|
||||
runs successfully, a commit is made; if the viewfunc produces an exception,
|
||||
a rollback is made. This is one of the most common ways to do transaction
|
||||
control in web apps.
|
||||
control in Web apps.
|
||||
"""
|
||||
def inner_commit_on_success(func, db=None):
|
||||
def _commit_on_success(*args, **kw):
|
||||
|
|
|
@ -7,7 +7,7 @@ Sample usage:
|
|||
>>> feed = feedgenerator.Rss201rev2Feed(
|
||||
... title=u"Poynter E-Media Tidbits",
|
||||
... link=u"http://www.poynter.org/column.asp?id=31",
|
||||
... description=u"A group weblog by the sharpest minds in online media/journalism/publishing.",
|
||||
... description=u"A group Weblog by the sharpest minds in online media/journalism/publishing.",
|
||||
... language=u"en",
|
||||
... )
|
||||
>>> feed.add_item(
|
||||
|
|
|
@ -34,7 +34,7 @@ CSRF_FAILRE_TEMPLATE = """
|
|||
<p>CSRF verification failed. Request aborted.</p>
|
||||
{% if no_referer %}
|
||||
<p>You are seeing this message because this HTTPS site requires a 'Referer
|
||||
header' to be sent by your web browser, but none was sent. This header is
|
||||
header' to be sent by your Web browser, but none was sent. This header is
|
||||
required for security reasons, to ensure that your browser is not being
|
||||
hijacked by third parties.</p>
|
||||
|
||||
|
|
|
@ -368,14 +368,14 @@ Forcing the URL prefix to a particular value
|
|||
============================================
|
||||
|
||||
Because many of these fastcgi-based solutions require rewriting the URL at
|
||||
some point inside the webserver, the path information that Django sees may not
|
||||
some point inside the Web server, the path information that Django sees may not
|
||||
resemble the original URL that was passed in. This is a problem if the Django
|
||||
application is being served from under a particular prefix and you want your
|
||||
URLs from the ``{% url %}`` tag to look like the prefix, rather than the
|
||||
rewritten version, which might contain, for example, ``mysite.fcgi``.
|
||||
|
||||
Django makes a good attempt to work out what the real script name prefix
|
||||
should be. In particular, if the webserver sets the ``SCRIPT_URL`` (specific
|
||||
should be. In particular, if the Web server sets the ``SCRIPT_URL`` (specific
|
||||
to Apache's mod_rewrite), or ``REDIRECT_URL`` (set by a few servers, including
|
||||
Apache + mod_rewrite in some situations), Django will work out the original
|
||||
prefix automatically.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
Deploying Django
|
||||
================
|
||||
|
||||
Django's chock-full of shortcuts to make web developer's lives easier, but all
|
||||
Django's chock-full of shortcuts to make Web developer's lives easier, but all
|
||||
those tools are of no use if you can't easily deploy your sites. Since Django's
|
||||
inception, ease of deployment has been a major goal. There's a number of good
|
||||
ways to easily deploy Django:
|
||||
|
|
|
@ -317,7 +317,7 @@ project (or somewhere else) that contains something like the following:
|
|||
import os
|
||||
os.environ['PYTHON_EGG_CACHE'] = '/some/directory'
|
||||
|
||||
Here, ``/some/directory`` is a directory that the Apache webserver process can
|
||||
Here, ``/some/directory`` is a directory that the Apache Web server process can
|
||||
write to. It will be used as the location for any unpacking of code the eggs
|
||||
need to do.
|
||||
|
||||
|
|
|
@ -55,7 +55,7 @@ not found" errors). Django sends emails about 404 errors when:
|
|||
If those conditions are met, Django will e-mail the users listed in the
|
||||
:setting:`MANAGERS` setting whenever your code raises a 404 and the request has
|
||||
a referer. (It doesn't bother to e-mail for 404s that don't have a referer --
|
||||
those are usually just people typing in broken URLs or broken web 'bots).
|
||||
those are usually just people typing in broken URLs or broken Web 'bots).
|
||||
|
||||
You can tell Django to stop reporting particular 404s by tweaking the
|
||||
:setting:`IGNORABLE_404_ENDS` and :setting:`IGNORABLE_404_STARTS` settings. Both
|
||||
|
|
|
@ -51,7 +51,7 @@ on top of Jython.
|
|||
.. _`django-jython`: http://code.google.com/p/django-jython/
|
||||
|
||||
To install it, follow the `installation instructions`_ detailed on the project
|
||||
website. Also, read the `database backends`_ documentation there.
|
||||
Web site. Also, read the `database backends`_ documentation there.
|
||||
|
||||
.. _`installation instructions`: http://code.google.com/p/django-jython/wiki/Install
|
||||
.. _`database backends`: http://code.google.com/p/django-jython/wiki/DatabaseBackends
|
||||
|
|
|
@ -20,10 +20,10 @@ Journal-World`_ of Lawrence, Kansas, USA.
|
|||
Adrian lives in Chicago, USA.
|
||||
|
||||
`Simon Willison`_
|
||||
Simon is a well-respected web developer from England. He had a one-year
|
||||
Simon is a well-respected Web developer from England. He had a one-year
|
||||
internship at World Online, during which time he and Adrian developed Django
|
||||
from scratch. The most enthusiastic Brit you'll ever meet, he's passionate
|
||||
about best practices in web development and maintains a well-read
|
||||
about best practices in Web development and maintains a well-read
|
||||
`web-development blog`_.
|
||||
|
||||
Simon lives in Brighton, England.
|
||||
|
@ -33,13 +33,13 @@ Journal-World`_ of Lawrence, Kansas, USA.
|
|||
around Django and related open source technologies. A good deal of Jacob's
|
||||
work time is devoted to working on Django. Jacob previously worked at World
|
||||
Online, where Django was invented, where he was the lead developer of
|
||||
Ellington, a commercial web publishing platform for media companies.
|
||||
Ellington, a commercial Web publishing platform for media companies.
|
||||
|
||||
Jacob lives in Lawrence, Kansas, USA.
|
||||
|
||||
`Wilson Miner`_
|
||||
Wilson's design-fu is what makes Django look so nice. He designed the
|
||||
website you're looking at right now, as well as Django's acclaimed admin
|
||||
Web site you're looking at right now, as well as Django's acclaimed admin
|
||||
interface. Wilson is the designer for EveryBlock_.
|
||||
|
||||
Wilson lives in San Francisco, USA.
|
||||
|
@ -89,7 +89,7 @@ and have free rein to hack on all parts of Django.
|
|||
Russell studied physics as an undergraduate, and studied neural networks for
|
||||
his PhD. His first job was with a startup in the defense industry developing
|
||||
simulation frameworks. Over time, mostly through work with Django, he's
|
||||
become more involved in web development.
|
||||
become more involved in Web development.
|
||||
|
||||
Russell has helped with several major aspects of Django, including a
|
||||
couple major internal refactorings, creation of the test system, and more.
|
||||
|
@ -134,7 +134,7 @@ Joseph Kocherhans
|
|||
|
||||
`Brian Rosner`_
|
||||
Brian is currently the tech lead at Eldarion_ managing and developing
|
||||
Django / Pinax_ based websites. He enjoys learning more about programming
|
||||
Django / Pinax_ based Web sites. He enjoys learning more about programming
|
||||
languages and system architectures and contributing to open source
|
||||
projects. Brian is the host of the `Django Dose`_ podcasts.
|
||||
|
||||
|
@ -180,7 +180,7 @@ Karen Tracey
|
|||
Karen has a background in distributed operating systems (graduate school),
|
||||
communications software (industry) and crossword puzzle construction
|
||||
(freelance). The last of these brought her to Django, in late 2006, when
|
||||
she set out to put a web front-end on her crossword puzzle database.
|
||||
she set out to put a Web front-end on her crossword puzzle database.
|
||||
That done, she stuck around in the community answering questions, debugging
|
||||
problems, etc. -- because coding puzzles are as much fun as word puzzles.
|
||||
|
||||
|
@ -190,7 +190,7 @@ Karen Tracey
|
|||
Jannis graduated in media design from `Bauhaus-University Weimar`_,
|
||||
is the author of a number of pluggable Django apps and likes to
|
||||
contribute to Open Source projects like Pinax_. He currently works as
|
||||
a freelance web developer and designer.
|
||||
a freelance Web developer and designer.
|
||||
|
||||
Jannis lives in Berlin, Germany.
|
||||
|
||||
|
@ -262,7 +262,7 @@ Specialists
|
|||
`James Bennett`_
|
||||
James is Django's release manager; he also contributes to the documentation.
|
||||
|
||||
James came to web development from philosophy when he discovered
|
||||
James came to Web development from philosophy when he discovered
|
||||
that programmers get to argue just as much while collecting much
|
||||
better pay. He lives in Lawrence, Kansas, where he works for the
|
||||
Journal-World developing Ellington. He `keeps a blog`_, has
|
||||
|
|
|
@ -22,7 +22,7 @@ The Django source code repository uses `Subversion`_ to track changes
|
|||
to the code over time, so you'll need a copy of the Subversion client
|
||||
(a program called ``svn``) on your computer, and you'll want to
|
||||
familiarize yourself with the basics of how Subversion
|
||||
works. Subversion's web site offers downloads for various operating
|
||||
works. Subversion's Web site offers downloads for various operating
|
||||
systems, and `a free online book`_ is available to help you get up to
|
||||
speed with using Subversion.
|
||||
|
||||
|
@ -34,7 +34,7 @@ repository address instead. At the top level of the repository are two
|
|||
directories: ``django`` contains the full source code for all Django
|
||||
releases, while ``djangoproject.com`` contains the source code and
|
||||
templates for the `djangoproject.com <http://www.djangoproject.com/>`_
|
||||
web site. For trying out in-development Django code, or contributing
|
||||
Web site. For trying out in-development Django code, or contributing
|
||||
to Django, you'll always want to check out code from some location in
|
||||
the ``django`` directory.
|
||||
|
||||
|
@ -58,7 +58,7 @@ into three areas:
|
|||
|
||||
.. _Subversion: http://subversion.tigris.org/
|
||||
.. _a free online book: http://svnbook.red-bean.com/
|
||||
.. _A friendly web-based interface for browsing the code: http://code.djangoproject.com/browser/
|
||||
.. _A friendly Web-based interface for browsing the code: http://code.djangoproject.com/browser/
|
||||
|
||||
|
||||
Working with Django's trunk
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
Getting started
|
||||
===============
|
||||
|
||||
New to Django? Or to web development in general? Well, you came to the right
|
||||
New to Django? Or to Web development in general? Well, you came to the right
|
||||
place: read this material to quickly get up and running.
|
||||
|
||||
.. toctree::
|
||||
|
|
|
@ -263,7 +263,7 @@ so you can focus on writing code rather than creating directories.
|
|||
.. admonition:: Projects vs. apps
|
||||
|
||||
What's the difference between a project and an app? An app is a Web
|
||||
application that does something -- e.g., a weblog system, a database of
|
||||
application that does something -- e.g., a Weblog system, a database of
|
||||
public records or a simple poll app. A project is a collection of
|
||||
configuration and apps for a particular Web site. A project can contain
|
||||
multiple apps. An app can be in multiple projects.
|
||||
|
|
|
@ -10,7 +10,7 @@ Philosophy
|
|||
==========
|
||||
|
||||
A view is a "type" of Web page in your Django application that generally serves
|
||||
a specific function and has a specific template. For example, in a weblog
|
||||
a specific function and has a specific template. For example, in a Weblog
|
||||
application, you might have the following views:
|
||||
|
||||
* Blog homepage -- displays the latest few entries.
|
||||
|
|
|
@ -36,7 +36,7 @@ Django's main documentation is broken up into "chunks" designed to fill
|
|||
different needs:
|
||||
|
||||
* The :doc:`introductory material </intro/index>` is designed for people new
|
||||
to Django -- or to web development in general. It doesn't cover anything
|
||||
to Django -- or to Web development in general. It doesn't cover anything
|
||||
in depth, but instead gives a high-level overview of how developing in
|
||||
Django "feels".
|
||||
|
||||
|
@ -166,7 +166,7 @@ You can get a local copy of the HTML documentation following a few easy steps:
|
|||
|
||||
* Django's documentation uses a system called Sphinx__ to convert from
|
||||
plain text to HTML. You'll need to install Sphinx by either downloading
|
||||
and installing the package from the Sphinx website, or by Python's
|
||||
and installing the package from the Sphinx Web site, or by Python's
|
||||
``easy_install``:
|
||||
|
||||
.. code-block:: bash
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
.TH "daily_cleanup.py" "1" "August 2007" "Django Project" ""
|
||||
.SH "NAME"
|
||||
daily_cleanup.py \- Database clean-up for the Django web framework
|
||||
daily_cleanup.py \- Database clean-up for the Django Web framework
|
||||
.SH "SYNOPSIS"
|
||||
.B daily_cleanup.py
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
.TH "django-admin.py" "1" "March 2008" "Django Project" ""
|
||||
.SH "NAME"
|
||||
django\-admin.py \- Utility script for the Django web framework
|
||||
django\-admin.py \- Utility script for the Django Web framework
|
||||
.SH "SYNOPSIS"
|
||||
.B django\-admin.py
|
||||
.I <action>
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
.TH "gather_profile_stats.py" "1" "August 2007" "Django Project" ""
|
||||
.SH "NAME"
|
||||
gather_profile_stats.py \- Performance analysis tool for the Django web
|
||||
gather_profile_stats.py \- Performance analysis tool for the Django Web
|
||||
framework
|
||||
.SH "SYNOPSIS"
|
||||
.B python gather_profile_stats.py
|
||||
|
|
|
@ -125,7 +125,7 @@ Contributed applications (``django.contrib``)
|
|||
|
||||
While we'll make every effort to keep these APIs stable -- and have no plans to
|
||||
break any contrib apps -- this is an area that will have more flux between
|
||||
releases. As the web evolves, Django must evolve with it.
|
||||
releases. As the Web evolves, Django must evolve with it.
|
||||
|
||||
However, any changes to contrib apps will come with an important guarantee:
|
||||
we'll make sure it's always possible to use an older version of a contrib app if
|
||||
|
|
|
@ -29,7 +29,7 @@ and uses a two-step process to enable moderation for any given model:
|
|||
model class and the class which specifies its moderation options.
|
||||
|
||||
A simple example is the best illustration of this. Suppose we have the
|
||||
following model, which would represent entries in a weblog::
|
||||
following model, which would represent entries in a Weblog::
|
||||
|
||||
from django.db import models
|
||||
|
||||
|
|
|
@ -8,7 +8,7 @@ Deploying GeoDjango
|
|||
not thread safe at this time. Thus, it is *highly* recommended
|
||||
to not use threading when deploying -- in other words, use a
|
||||
an appropriate configuration of Apache or the prefork method
|
||||
when using FastCGI through another web server.
|
||||
when using FastCGI through another Web server.
|
||||
|
||||
Apache
|
||||
======
|
||||
|
|
|
@ -9,8 +9,8 @@ GeoDjango
|
|||
.. module:: django.contrib.gis
|
||||
:synopsis: Geographic Information System (GIS) extensions for Django
|
||||
|
||||
GeoDjango intends to be a world-class geographic web framework. Its goal is to
|
||||
make it as easy as possible to build GIS web applications and harness the power
|
||||
GeoDjango intends to be a world-class geographic Web framework. Its goal is to
|
||||
make it as easy as possible to build GIS Web applications and harness the power
|
||||
of spatially enabled data.
|
||||
|
||||
.. toctree::
|
||||
|
|
|
@ -147,7 +147,7 @@ internal geometry representation used by GeoDjango (it's behind the "lazy"
|
|||
geometries). Specifically, the C API library is called (e.g., ``libgeos_c.so``)
|
||||
directly from Python using ctypes.
|
||||
|
||||
First, download GEOS 3.2 from the refractions website and untar the source
|
||||
First, download GEOS 3.2 from the refractions Web site and untar the source
|
||||
archive::
|
||||
|
||||
$ wget http://download.osgeo.org/geos/geos-3.2.2.tar.bz2
|
||||
|
@ -640,7 +640,7 @@ If you can't find the solution to your problem here then participate in the
|
|||
community! You can:
|
||||
|
||||
* Join the ``#geodjango`` IRC channel on FreeNode (may be accessed on the
|
||||
web via `Mibbit`__). Please be patient and polite -- while you may not
|
||||
Web via `Mibbit`__). Please be patient and polite -- while you may not
|
||||
get an immediate response, someone will attempt to answer your question
|
||||
as soon as they see it.
|
||||
* Ask your question on the `GeoDjango`__ mailing list.
|
||||
|
@ -1085,7 +1085,7 @@ Windows XP
|
|||
Python
|
||||
^^^^^^
|
||||
|
||||
First, download the `Python 2.6 installer`__ from the Python website. Next,
|
||||
First, download the `Python 2.6 installer`__ from the Python Web site. Next,
|
||||
execute the installer and use defaults, e.g., keep 'Install for all users'
|
||||
checked and the installation path set as ``C:\Python26``.
|
||||
|
||||
|
@ -1101,7 +1101,7 @@ PostgreSQL
|
|||
^^^^^^^^^^
|
||||
|
||||
First, select a mirror and download the latest `PostgreSQL 8.3 installer`__ from
|
||||
the EnterpriseDB website.
|
||||
the EnterpriseDB Web site.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
|
@ -97,7 +97,7 @@ corresponds to the projection system that will be used to interpret the data
|
|||
in the spatial database. [#fnsrid]_ Projection systems give the context to the
|
||||
coordinates that specify a location. Although the details of `geodesy`__ are
|
||||
beyond the scope of this documentation, the general problem is that the earth
|
||||
is spherical and representations of the earth (e.g., paper maps, web maps)
|
||||
is spherical and representations of the earth (e.g., paper maps, Web maps)
|
||||
are not.
|
||||
|
||||
Most people are familiar with using latitude and longitude to reference a
|
||||
|
@ -133,7 +133,7 @@ Additional Resources:
|
|||
|
||||
* `spatialreference.org`__: A Django-powered database of spatial reference
|
||||
systems.
|
||||
* `The State Plane Coordinate System`__: A website covering the various
|
||||
* `The State Plane Coordinate System`__: A Web site covering the various
|
||||
projection systems used in the United States. Much of the U.S. spatial
|
||||
data encountered will be in one of these coordinate systems rather than
|
||||
in a geographic coordinate system such as WGS84.
|
||||
|
|
|
@ -6,8 +6,8 @@ Introduction
|
|||
============
|
||||
|
||||
GeoDjango is an add-on for Django that turns it into a world-class geographic
|
||||
web framework. GeoDjango strives to make at as simple as possible to create
|
||||
geographic web applications, like location-based services. Some features include:
|
||||
Web framework. GeoDjango strives to make at as simple as possible to create
|
||||
geographic Web applications, like location-based services. Some features include:
|
||||
|
||||
* Django model fields for `OGC`_ geometries.
|
||||
* Extensions to Django's ORM for the querying and manipulation of spatial data.
|
||||
|
@ -25,7 +25,7 @@ yourself with basic Django concepts.
|
|||
please consult the :ref:`installation documentation <ref-gis-install>`
|
||||
for more details.
|
||||
|
||||
This tutorial will guide you through the creation of a geographic web
|
||||
This tutorial will guide you through the creation of a geographic Web
|
||||
application for viewing the `world borders`_. [#]_ Some of the code
|
||||
used in this tutorial is taken from and/or inspired by the `GeoDjango
|
||||
basic apps`_ project. [#]_
|
||||
|
@ -197,7 +197,7 @@ as well as detailed information for each attribute field. For example,
|
|||
``FIPS: String (2.0)`` indicates that there's a ``FIPS`` character field
|
||||
with a maximum length of 2; similarly, ``LON: Real (8.3)`` is a floating-point
|
||||
field that holds a maximum of 8 digits up to three decimal places. Although
|
||||
this information may be found right on the `world borders`_ website, this shows
|
||||
this information may be found right on the `world borders`_ Web site, this shows
|
||||
you how to determine this information yourself when such metadata is not
|
||||
provided.
|
||||
|
||||
|
|
|
@ -8,7 +8,7 @@ GeoDjango Utilities
|
|||
:synopsis: GeoDjango's collection of utilities.
|
||||
|
||||
The :mod:`django.contrib.gis.utils` module contains various utilities that are
|
||||
useful in creating geospatial web applications.
|
||||
useful in creating geospatial Web applications.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
@ -76,7 +76,7 @@ Sitemap classes
|
|||
A :class:`~django.contrib.sitemaps.Sitemap` class is a simple Python
|
||||
class that represents a "section" of entries in your sitemap. For example,
|
||||
one :class:`~django.contrib.sitemaps.Sitemap` class could represent
|
||||
all the entries of your weblog, while another could represent all of the
|
||||
all the entries of your Weblog, while another could represent all of the
|
||||
events in your events calendar.
|
||||
|
||||
In the simplest case, all these sections get lumped together into one
|
||||
|
|
|
@ -3,7 +3,7 @@ The "sites" framework
|
|||
=====================
|
||||
|
||||
.. module:: django.contrib.sites
|
||||
:synopsis: Lets you operate multiple web sites from the same database and
|
||||
:synopsis: Lets you operate multiple Web sites from the same database and
|
||||
Django project
|
||||
|
||||
Django comes with an optional "sites" framework. It's a hook for associating
|
||||
|
|
|
@ -197,7 +197,7 @@ Customizing widget instances
|
|||
When Django renders a widget as HTML, it only renders the bare minimum
|
||||
HTML - Django doesn't add a class definition, or any other widget-specific
|
||||
attributes. This means that all 'TextInput' widgets will appear the same
|
||||
on your web page.
|
||||
on your Web page.
|
||||
|
||||
If you want to make one widget look different to another, you need to
|
||||
specify additional attributes for each widget. When you specify a
|
||||
|
@ -222,7 +222,7 @@ each widget will be rendered exactly the same::
|
|||
<tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr>
|
||||
|
||||
|
||||
On a real web page, you probably don't want every widget to look the same. You
|
||||
On a real Web page, you probably don't want every widget to look the same. You
|
||||
might want a larger input element for the comment, and you might want the 'name'
|
||||
widget to have some special CSS class. To do this, you use the ``attrs``
|
||||
argument when creating the widget:
|
||||
|
|
|
@ -193,7 +193,7 @@ Transaction middleware
|
|||
----------------------
|
||||
|
||||
.. module:: django.middleware.transaction
|
||||
:synopsis: Middleware binding a database transaction to each web request.
|
||||
:synopsis: Middleware binding a database transaction to each Web request.
|
||||
|
||||
.. class:: django.middleware.transaction.TransactionMiddleware
|
||||
|
||||
|
|
|
@ -9,7 +9,7 @@ material presented in the :doc:`model </topics/db/models>` and :doc:`database
|
|||
query </topics/db/queries>` guides, so you'll probably want to read and
|
||||
understand those documents before reading this one.
|
||||
|
||||
Throughout this reference we'll use the :ref:`example weblog models
|
||||
Throughout this reference we'll use the :ref:`example Weblog models
|
||||
<queryset-model-example>` presented in the :doc:`database query guide
|
||||
</topics/db/queries>`.
|
||||
|
||||
|
|
|
@ -9,7 +9,7 @@ material presented in the :doc:`model </topics/db/models>` and :doc:`database
|
|||
query </topics/db/queries>` guides, so you'll probably want to read and
|
||||
understand those documents before reading this one.
|
||||
|
||||
Throughout this reference we'll use the :ref:`example weblog models
|
||||
Throughout this reference we'll use the :ref:`example Weblog models
|
||||
<queryset-model-example>` presented in the :doc:`database query guide
|
||||
</topics/db/queries>`.
|
||||
|
||||
|
|
|
@ -137,7 +137,7 @@ All attributes except ``session`` should be considered read-only.
|
|||
* ``QUERY_STRING`` -- The query string, as a single (unparsed) string.
|
||||
* ``REMOTE_ADDR`` -- The IP address of the client.
|
||||
* ``REMOTE_HOST`` -- The hostname of the client.
|
||||
* ``REMOTE_USER`` -- The user authenticated by the web server, if any.
|
||||
* ``REMOTE_USER`` -- The user authenticated by the Web server, if any.
|
||||
* ``REQUEST_METHOD`` -- A string such as ``"GET"`` or ``"POST"``.
|
||||
* ``SERVER_NAME`` -- The hostname of the server.
|
||||
* ``SERVER_PORT`` -- The port of the server.
|
||||
|
|
|
@ -2102,7 +2102,7 @@ See the :doc:`markup documentation </ref/contrib/markup>`.
|
|||
django.contrib.webdesign
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A collection of template tags that can be useful while designing a website,
|
||||
A collection of template tags that can be useful while designing a Web site,
|
||||
such as a generator of Lorem Ipsum text. See :doc:`/ref/contrib/webdesign`.
|
||||
|
||||
i18n
|
||||
|
|
|
@ -193,7 +193,7 @@ Sample usage::
|
|||
>>> feed = feedgenerator.Rss201rev2Feed(
|
||||
... title=u"Poynter E-Media Tidbits",
|
||||
... link=u"http://www.poynter.org/column.asp?id=31",
|
||||
... description=u"A group weblog by the sharpest minds in online media/journalism/publishing.",
|
||||
... description=u"A group Weblog by the sharpest minds in online media/journalism/publishing.",
|
||||
... language=u"en",
|
||||
... )
|
||||
>>> feed.add_item(
|
||||
|
|
|
@ -6,7 +6,7 @@ Welcome to Django 1.0!
|
|||
|
||||
We've been looking forward to this moment for over three years, and it's finally
|
||||
here. Django 1.0 represents a the largest milestone in Django's development to
|
||||
date: a web framework that a group of perfectionists can truly be proud of.
|
||||
date: a Web framework that a group of perfectionists can truly be proud of.
|
||||
|
||||
Django 1.0 represents over three years of community development as an Open
|
||||
Source project. Django's received contributions from hundreds of developers,
|
||||
|
|
|
@ -142,7 +142,7 @@ release, including:
|
|||
notably, the memcached backend -- these operations will be atomic, and
|
||||
quite fast.
|
||||
|
||||
* Django now can :doc:`easily delegate authentication to the web server
|
||||
* Django now can :doc:`easily delegate authentication to the Web server
|
||||
</howto/auth-remote-user>` via a new authentication backend that supports
|
||||
the standard ``REMOTE_USER`` environment variable used for this purpose.
|
||||
|
||||
|
|
|
@ -426,7 +426,7 @@ Other new features and changes introduced since Django 1.0 include:
|
|||
notably, the memcached backend -- these operations will be atomic, and
|
||||
quite fast.
|
||||
|
||||
* Django now can :doc:`easily delegate authentication to the web server
|
||||
* Django now can :doc:`easily delegate authentication to the Web server
|
||||
</howto/auth-remote-user>` via a new authentication backend that supports
|
||||
the standard ``REMOTE_USER`` environment variable used for this purpose.
|
||||
|
||||
|
|
|
@ -658,7 +658,7 @@ How to log a user out
|
|||
|
||||
When you call :func:`~django.contrib.auth.logout()`, the session data for
|
||||
the current request is completely cleaned out. All existing data is
|
||||
removed. This is to prevent another person from using the same web browser
|
||||
removed. This is to prevent another person from using the same Web browser
|
||||
to log in and have access to the previous user's session data. If you want
|
||||
to put anything into the session that will be available to the user
|
||||
immediately after logging out, do that *after* calling
|
||||
|
|
|
@ -6,7 +6,7 @@ Conditional View Processing
|
|||
|
||||
HTTP clients can send a number of headers to tell the server about copies of a
|
||||
resource that they have already seen. This is commonly used when retrieving a
|
||||
web page (using an HTTP ``GET`` request) to avoid sending all the data for
|
||||
Web page (using an HTTP ``GET`` request) to avoid sending all the data for
|
||||
something the client has already retrieved. However, the same headers can be
|
||||
used for all HTTP methods (``POST``, ``PUT``, ``DELETE``, etc).
|
||||
|
||||
|
|
|
@ -68,7 +68,7 @@ Understand cached attributes
|
|||
|
||||
As well as caching of the whole ``QuerySet``, there is caching of the result of
|
||||
attributes on ORM objects. In general, attributes that are not callable will be
|
||||
cached. For example, assuming the :ref:`example weblog models
|
||||
cached. For example, assuming the :ref:`example Weblog models
|
||||
<queryset-model-example>`:
|
||||
|
||||
>>> entry = Entry.objects.get(id=1)
|
||||
|
|
|
@ -11,7 +11,7 @@ API. Refer to the :doc:`data model reference </ref/models/index>` for full
|
|||
details of all the various model lookup options.
|
||||
|
||||
Throughout this guide (and in the reference), we'll refer to the following
|
||||
models, which comprise a weblog application:
|
||||
models, which comprise a Weblog application:
|
||||
|
||||
.. _queryset-model-example:
|
||||
|
||||
|
|
|
@ -574,7 +574,7 @@ Testing e-mail sending
|
|||
======================
|
||||
|
||||
There are times when you do not want Django to send e-mails at
|
||||
all. For example, while developing a website, you probably don't want
|
||||
all. For example, while developing a Web site, you probably don't want
|
||||
to send out thousands of e-mails -- but you may want to validate that
|
||||
e-mails will be sent to the right people under the right conditions,
|
||||
and that those e-mails will contain the correct content.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
Form Media
|
||||
==========
|
||||
|
||||
Rendering an attractive and easy-to-use web form requires more than just
|
||||
Rendering an attractive and easy-to-use Web form requires more than just
|
||||
HTML - it also requires CSS stylesheets, and if you want to use fancy
|
||||
"Web2.0" widgets, you may also need to include some JavaScript on each
|
||||
page. The exact combination of CSS and JavaScript that is required for
|
||||
|
@ -14,7 +14,7 @@ you can define a custom Calendar widget. This widget can then be associated
|
|||
with the CSS and JavaScript that is required to render the calendar. When
|
||||
the Calendar widget is used on a form, Django is able to identify the CSS and
|
||||
JavaScript files that are required, and provide the list of file names
|
||||
in a form suitable for easy inclusion on your web page.
|
||||
in a form suitable for easy inclusion on your Web page.
|
||||
|
||||
.. admonition:: Media and Django Admin
|
||||
|
||||
|
|
|
@ -152,7 +152,7 @@ of caveats:
|
|||
define ``__init__`` as requiring any arguments.
|
||||
|
||||
* Unlike the ``process_*`` methods which get called once per request,
|
||||
``__init__`` gets called only *once*, when the web server starts up.
|
||||
``__init__`` gets called only *once*, when the Web server starts up.
|
||||
|
||||
Marking middleware as unused
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
@ -28,7 +28,7 @@ Install Apache and mod_wsgi
|
|||
=============================
|
||||
|
||||
If you just want to experiment with Django, skip ahead to the next section;
|
||||
Django includes a lightweight web server you can use for testing, so you won't
|
||||
Django includes a lightweight Web server you can use for testing, so you won't
|
||||
need to set up Apache until you're ready to deploy Django in production.
|
||||
|
||||
If you want to use Django on a production site, use Apache with `mod_wsgi`_.
|
||||
|
|
|
@ -9,7 +9,7 @@ class CustomColumnsTests(TestCase):
|
|||
a1 = Author.objects.create(first_name="John", last_name="Smith")
|
||||
a2 = Author.objects.create(first_name="Peter", last_name="Jones")
|
||||
|
||||
art = Article.objects.create(headline="Django lets you build web apps easily")
|
||||
art = Article.objects.create(headline="Django lets you build Web apps easily")
|
||||
art.authors = [a1, a2]
|
||||
|
||||
# Although the table and column names on Author have been set to custom
|
||||
|
@ -58,7 +58,7 @@ class CustomColumnsTests(TestCase):
|
|||
# Get the articles for an author
|
||||
self.assertQuerysetEqual(
|
||||
a.article_set.all(), [
|
||||
"Django lets you build web apps easily",
|
||||
"Django lets you build Web apps easily",
|
||||
],
|
||||
lambda a: a.headline
|
||||
)
|
||||
|
|
|
@ -22,7 +22,7 @@ class CustomColumnRegression(TestCase):
|
|||
self.authors = [self.a1, self.a2]
|
||||
|
||||
def test_basic_creation(self):
|
||||
art = Article(headline='Django lets you build web apps easily', primary_author=self.a1)
|
||||
art = Article(headline='Django lets you build Web apps easily', primary_author=self.a1)
|
||||
art.save()
|
||||
art.authors = [self.a1, self.a2]
|
||||
|
||||
|
@ -68,7 +68,7 @@ class CustomColumnRegression(TestCase):
|
|||
)
|
||||
|
||||
def test_m2m_table(self):
|
||||
art = Article.objects.create(headline='Django lets you build web apps easily', primary_author=self.a1)
|
||||
art = Article.objects.create(headline='Django lets you build Web apps easily', primary_author=self.a1)
|
||||
art.authors = self.authors
|
||||
self.assertQuerysetEqual(
|
||||
art.authors.all().order_by('last_name'),
|
||||
|
@ -76,7 +76,7 @@ class CustomColumnRegression(TestCase):
|
|||
)
|
||||
self.assertQuerysetEqual(
|
||||
self.a1.article_set.all(),
|
||||
['<Article: Django lets you build web apps easily>']
|
||||
['<Article: Django lets you build Web apps easily>']
|
||||
)
|
||||
self.assertQuerysetEqual(
|
||||
art.authors.filter(last_name='Jones'),
|
||||
|
|
|
@ -142,7 +142,7 @@ class FileStorageTests(unittest.TestCase):
|
|||
|
||||
def test_file_url(self):
|
||||
"""
|
||||
File storage returns a url to access a given file from the web.
|
||||
File storage returns a url to access a given file from the Web.
|
||||
"""
|
||||
self.assertEqual(self.storage.url('test.file'),
|
||||
'%s%s' % (self.storage.base_url, 'test.file'))
|
||||
|
|
Loading…
Reference in New Issue