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.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14069 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
2cadc6b10a
commit
a904e55859
|
@ -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)
|
||||
|
|
|
@ -117,7 +117,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()
|
||||
|
||||
|
|
|
@ -216,7 +216,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>
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ to the Web server, which, in turn, passes it back to the client's Web browser.
|
|||
|
||||
Like mod_wsgi, FastCGI allows code to stay in memory, allowing requests to be
|
||||
served with no startup time. While mod_wsgi can either be configured embedded
|
||||
in the Apache webserver process or as a separate daemon process, a FastCGI
|
||||
in the Apache Web server process or as a separate daemon process, a FastCGI
|
||||
process never runs inside the Web server process, always in a separate,
|
||||
persistent process.
|
||||
|
||||
|
@ -367,14 +367,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
|
||||
|
|
|
@ -210,7 +210,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
|
||||
|
@ -235,7 +235,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>`.
|
||||
|
||||
|
|
|
@ -37,12 +37,12 @@ All attributes except ``session`` should be considered read-only.
|
|||
|
||||
.. attribute:: HttpRequest.path_info
|
||||
|
||||
Under some web server configurations, the portion of the URL after the host
|
||||
Under some Web server configurations, the portion of the URL after the host
|
||||
name is split up into a script prefix portion and a path info portion
|
||||
(this happens, for example, when using the ``django.root`` option
|
||||
with the :doc:`modpython handler from Apache </howto/deployment/modpython>`).
|
||||
The ``path_info`` attribute always contains the path info portion of the
|
||||
path, no matter what web server is being used. Using this instead of
|
||||
path, no matter what Web server is being used. Using this instead of
|
||||
attr:`~HttpRequest.path` can make your code much easier to move between test
|
||||
and deployment servers.
|
||||
|
||||
|
@ -152,7 +152,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:
|
||||
|
||||
|
|
|
@ -580,7 +580,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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
@ -938,10 +938,10 @@ Normally, you should always use :func:`~django.core.urlresolvers.reverse` or
|
|||
:func:`~django.db.models.permalink` to define URLs within your application.
|
||||
However, if your application constructs part of the URL hierarchy itself, you
|
||||
may occasionally need to generate URLs. In that case, you need to be able to
|
||||
find the base URL of the Django project within its web server
|
||||
find the base URL of the Django project within its Web server
|
||||
(normally, :func:`~django.core.urlresolvers.reverse` takes care of this for
|
||||
you). In that case, you can call ``get_script_prefix()``, which will return the
|
||||
script prefix portion of the URL for your Django project. If your Django
|
||||
project is at the root of its webserver, this is always ``"/"``, but it can be
|
||||
project is at the root of its Web server, this is always ``"/"``, but it can be
|
||||
changed, for instance by using ``django.root`` (see :doc:`How to use
|
||||
Django with Apache and mod_python </howto/deployment/modpython>`).
|
||||
|
|
|
@ -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
|
||||
section; 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.
|
||||
|
||||
|
@ -40,9 +40,9 @@ memory when the server starts. Code stays in memory throughout the
|
|||
life of an Apache process, which leads to significant performance
|
||||
gains over other server arrangements. In daemon mode, mod_wsgi spawns
|
||||
an independent daemon process that handles requests. The daemon
|
||||
process can run as a different user than the webserver, possibly
|
||||
process can run as a different user than the Web server, possibly
|
||||
leading to improved security, and the daemon process can be restarted
|
||||
without restarting the entire Apache webserver, possibly making
|
||||
without restarting the entire Apache Web server, possibly making
|
||||
refreshing your codebase more seamless. Consult the mod_wsgi
|
||||
documentation to determine which mode is right for your setup. Make
|
||||
sure you have Apache installed, with the mod_wsgi module activated.
|
||||
|
|
|
@ -383,7 +383,7 @@ Django's logging extensions
|
|||
===========================
|
||||
|
||||
Django provides a number of utilities to handle the unique
|
||||
requirements of logging in webserver environment.
|
||||
requirements of logging in Web server environment.
|
||||
|
||||
Loggers
|
||||
-------
|
||||
|
|
|
@ -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'),
|
||||
|
|
|
@ -193,7 +193,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