From 7372ea159aa192757cc5383e6857c29ca2fc53c6 Mon Sep 17 00:00:00 2001 From: Gary Wilson Jr Date: Tue, 31 Mar 2009 07:01:01 +0000 Subject: [PATCH] Fixed #10389, #10501, #10502, #10540, #10562, #10563, #10564, #10565, #10568, #10569, #10614, #10617, #10619 -- Fixed several typos as well as a couple minor issues in the docs, patches from timo, nih, bthomas, rduffield, UloPe, and sebleier@gmail.com. git-svn-id: http://code.djangoproject.com/svn/django/trunk@10242 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- django/contrib/admin/validation.py | 2 +- docs/howto/custom-model-fields.txt | 14 +++++++------- docs/howto/deployment/fastcgi.txt | 8 +++----- docs/howto/deployment/modpython.txt | 14 ++++++-------- docs/intro/tutorial02.txt | 12 ++++++------ docs/ref/contrib/admin/index.txt | 2 +- docs/ref/databases.txt | 8 ++++---- docs/ref/models/instances.txt | 7 ++++--- docs/topics/db/aggregation.txt | 11 +++++------ docs/topics/db/models.txt | 5 +++-- docs/topics/forms/index.txt | 2 +- 11 files changed, 41 insertions(+), 44 deletions(-) diff --git a/django/contrib/admin/validation.py b/django/contrib/admin/validation.py index 24fa9aa978..4fdbd0d6f4 100644 --- a/django/contrib/admin/validation.py +++ b/django/contrib/admin/validation.py @@ -76,7 +76,7 @@ def validate(cls, model): field = opts.get_field_by_name(field_name)[0] except models.FieldDoesNotExist: raise ImproperlyConfigured("'%s.list_editable[%d]' refers to a " - "field, '%s', not defiend on %s." + "field, '%s', not defined on %s." % (cls.__name__, idx, field_name, model.__name__)) if field_name not in cls.list_display: raise ImproperlyConfigured("'%s.list_editable[%d]' refers to " diff --git a/docs/howto/custom-model-fields.txt b/docs/howto/custom-model-fields.txt index 056a54e193..6fe589f4a2 100644 --- a/docs/howto/custom-model-fields.txt +++ b/docs/howto/custom-model-fields.txt @@ -45,7 +45,7 @@ something like this:: self.east = east self.south = south self.west = west - + # ... (other possibly useful methods omitted) ... .. _Bridge: http://en.wikipedia.org/wiki/Contract_bridge @@ -203,7 +203,7 @@ parameters: :class:`ForeignKey`). For advanced use only. * :attr:`~django.db.models.Field.default` * :attr:`~django.db.models.Field.editable` - * :attr:`~django.db.models.Field.serialize`: If ``False``, the field will + * :attr:`~django.db.models.Field.serialize`: If ``False``, the field will not be serialized when the model is passed to Django's :ref:`serializers `. Defaults to ``True``. * :attr:`~django.db.models.Field.prepopulate_from` @@ -254,7 +254,7 @@ called when the attribute is initialized. Useful methods -------------- -Once you've created your :class:`~django.db.models.Field` subclass and set up up +Once you've created your :class:`~django.db.models.Field` subclass and set up the ``__metaclass__``, you might consider overriding a few standard methods, depending on your field's behavior. The list of methods below is in approximately decreasing order of importance, so start from the top. @@ -419,9 +419,9 @@ For example:: Same as the above, but called when the Field value must be *saved* to the database. As the default implementation just calls ``get_db_prep_value``, you -shouldn't need to implement this method unless your custom field need a special -conversion when being saved that is not the same as the used for normal query -parameters (which is implemented by ``get_db_prep_value``). +shouldn't need to implement this method unless your custom field needs a +special conversion when being saved that is not the same as the conversion used +for normal query parameters (which is implemented by ``get_db_prep_value``). Preprocessing values before saving ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -522,7 +522,7 @@ Continuing our ongoing example, we can write the :meth:`formfield` method as:: defaults.update(kwargs) return super(HandField, self).formfield(**defaults) -This assumes we're imported a ``MyFormField`` field class (which has its own +This assumes we've imported a ``MyFormField`` field class (which has its own default widget). This document doesn't cover the details of writing custom form fields. diff --git a/docs/howto/deployment/fastcgi.txt b/docs/howto/deployment/fastcgi.txt index 63f44eae19..2049cacf2a 100644 --- a/docs/howto/deployment/fastcgi.txt +++ b/docs/howto/deployment/fastcgi.txt @@ -1,8 +1,8 @@ .. _howto-deployment-fastcgi: -=========================================== -How to use Django with FastCGI, SCGI or AJP -=========================================== +============================================ +How to use Django with FastCGI, SCGI, or AJP +============================================ .. highlight:: bash @@ -379,5 +379,3 @@ have different script names in this case, but that is a rare situation. As an example of how to use it, if your Django configuration is serving all of the URLs under ``'/'`` and you wanted to use this setting, you would set ``FORCE_SCRIPT_NAME = ''`` in your settings file. - - diff --git a/docs/howto/deployment/modpython.txt b/docs/howto/deployment/modpython.txt index 8799b390fe..70f1e37749 100644 --- a/docs/howto/deployment/modpython.txt +++ b/docs/howto/deployment/modpython.txt @@ -17,8 +17,8 @@ performance gains over other server arrangements. Django requires Apache 2.x and mod_python 3.x, and you should use Apache's `prefork MPM`_, as opposed to the `worker MPM`_. -You may also be interested in :ref:`How to use Django with FastCGI, SCGI or AJP -` (which also covers SCGI and AJP). +You may also be interested in :ref:`How to use Django with FastCGI, SCGI, or +AJP `. .. _Apache: http://httpd.apache.org/ .. _mod_python: http://www.modpython.org/ @@ -38,7 +38,7 @@ Then edit your ``httpd.conf`` file and add the following:: SetHandler python-program PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mysite.settings - PythonOption django.root /mysite + PythonOption django.root /mysite PythonDebug On @@ -84,7 +84,7 @@ computer, you'll have to tell mod_python where your project can be found: SetHandler python-program PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mysite.settings - PythonOption django.root /mysite + PythonOption django.root /mysite PythonDebug On **PythonPath "['/path/to/project'] + sys.path"** @@ -273,7 +273,7 @@ Here are two recommended approaches: document root. This way, all of your Django-related files -- code **and** templates -- stay in one place, and you'll still be able to ``svn update`` your code to get the latest admin templates, if they change. - + 2. Or, copy the admin media files so that they live within your Apache document root. @@ -337,7 +337,7 @@ of which has to do with Django itself. 1. It may be because your Python code is importing the "pyexpat" module, which may conflict with the version embedded in Apache. For full information, see `Expat Causing Apache Crash`_. - + 2. It may be because you're running mod_python and mod_php in the same Apache instance, with MySQL as your database backend. In some cases, this causes a known mod_python issue due to version conflicts in PHP and @@ -361,5 +361,3 @@ as necessary. .. _Expat Causing Apache Crash: http://www.dscpl.com.au/articles/modpython-006.html .. _mod_python FAQ entry: http://modpython.org/FAQ/faqw.py?req=show&file=faq02.013.htp .. _Getting mod_python Working: http://www.dscpl.com.au/articles/modpython-001.html - - diff --git a/docs/intro/tutorial02.txt b/docs/intro/tutorial02.txt index 0d62c56a7b..c9b476db71 100644 --- a/docs/intro/tutorial02.txt +++ b/docs/intro/tutorial02.txt @@ -170,14 +170,14 @@ with the timestamp and username of the person who made the change: Customize the admin form ======================== -Take a few minutes to marvel at all the code you didn't have to write. When you -call ``admin.site.register(Poll)``, Django just lets you edit the object and -"guess" at how to display it within the admin. Often you'll want to control how -the admin looks and works. You'll do this by telling Django about the options +Take a few minutes to marvel at all the code you didn't have to write. By +registering the Poll model with ``admin.site.register(Poll)``, Django was able +to construct a default form representation. Often, you'll want to customize how +the admin form looks and works. You'll do this by telling Django the options you want when you register the object. -Let's see how this works by reordering the fields on the edit form. Replace the -``admin.site.register(Poll)`` line with:: +Let's see how this works by re-ordering the fields on the edit form. Replace +the ``admin.site.register(Poll)`` line with:: class PollAdmin(admin.ModelAdmin): fields = ['pub_date', 'question'] diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt index 4bea68d500..c2a8739dd4 100644 --- a/docs/ref/contrib/admin/index.txt +++ b/docs/ref/contrib/admin/index.txt @@ -677,7 +677,7 @@ The value is another dictionary; these arguments will be passed to A list of actions to make available on the change list page. See :ref:`ref-contrib-admin-actions` for details. -``actions_on_top``, ``actions_on_buttom`` +``actions_on_top``, ``actions_on_bottom`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Controls where on the page the actions bar appears. By default, the admin diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt index 63f78f7954..74a8145948 100644 --- a/docs/ref/databases.txt +++ b/docs/ref/databases.txt @@ -26,7 +26,7 @@ The implementation of the population statistics aggregates ``STDDEV_POP`` and faulty`_. Users of these releases of PostgreSQL are advised to upgrade to `Release 8.2.5`_ or later. Django will raise a ``NotImplementedError`` if you attempt to use the ``StdDev(sample=False)`` or ``Variance(sample=False)`` -aggregate with an database backend falls within the affected release range. +aggregate with a database backend that falls within the affected release range. .. _known to be faulty: http://archives.postgresql.org/pgsql-bugs/2007-07/msg00046.php .. _Release 8.2.5: http://developer.postgresql.org/pgdocs/postgres/release-8-2-5.html @@ -35,7 +35,7 @@ Transaction handling --------------------- :ref:`By default `, Django starts a transaction when a -database connection if first used and commits the result at the end of the +database connection is first used and commits the result at the end of the request/response handling. The PostgreSQL backends normally operate the same as any other Django backend in this respect. @@ -87,8 +87,8 @@ MySQL notes =========== Django expects the database to support transactions, referential integrity, -and Unicode support (UTF-8 encoding). Fortunately, MySQL_ has all these -features as available as far back as 3.23. While it may be possible to use +and Unicode (UTF-8 encoding). Fortunately, MySQL_ has all these +features available as far back as 3.23. While it may be possible to use 3.23 or 4.0, you'll probably have less trouble if you use 4.1 or 5.0. MySQL 4.1 diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt index f55ce65699..5e7151a89c 100644 --- a/docs/ref/models/instances.txt +++ b/docs/ref/models/instances.txt @@ -18,12 +18,13 @@ Throughout this reference we'll use the :ref:`example weblog models Creating objects ================ -To create a new instance of a model, just instantiate it like any other Python class: +To create a new instance of a model, just instantiate it like any other Python +class: .. class:: Model(**kwargs) -The keyword arguments to are simply the names of the fields you've defined on -your model. Note that instantiating a model in no way touches your database; for +The keyword arguments are simply the names of the fields you've defined on your +model. Note that instantiating a model in no way touches your database; for that, you need to ``save()``. Saving objects diff --git a/docs/topics/db/aggregation.txt b/docs/topics/db/aggregation.txt index 9f7ba6fa22..ade2f505a7 100644 --- a/docs/topics/db/aggregation.txt +++ b/docs/topics/db/aggregation.txt @@ -146,12 +146,11 @@ So far, we have dealt with aggregates over fields that belong to the model being queried. However, sometimes the value you want to aggregate will belong to a model that is related to the model you are querying. -When specifying the field to be aggregated in an aggregate functions, -Django will allow you to use the same -:ref:`double underscore notation ` that is used -when referring to related fields in filters. Django will then handle -any table joins that are required to retrieve and aggregate the -related value. +When specifying the field to be aggregated in an aggregate function, Django +will allow you to use the same :ref:`double underscore notation +` that is used when referring to related fields in +filters. Django will then handle any table joins that are required to retrieve +and aggregate the related value. For example, to find the price range of books offered in each store, you could use the annotation:: diff --git a/docs/topics/db/models.txt b/docs/topics/db/models.txt index eb61120fe3..797ebcb8c1 100644 --- a/docs/topics/db/models.txt +++ b/docs/topics/db/models.txt @@ -1019,10 +1019,11 @@ ordering or the default manager in the proxy, without having to alter the original. Proxy models are declared like normal models. You tell Django that it's a -proxy model by setting the :attr:`~django.db.models.Options.proxy` attribute to of the ``Meta`` class to ``True``. +proxy model by setting the :attr:`~django.db.models.Options.proxy` attribute of +the ``Meta`` class to ``True``. For example, suppose you want to add a method to the standard ``User`` model -that will make be used in your templates. You can do it like this:: +that will be used in your templates. You can do it like this:: from django.contrib.auth.models import User diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt index 47a29f334e..cb47639345 100644 --- a/docs/topics/forms/index.txt +++ b/docs/topics/forms/index.txt @@ -293,7 +293,7 @@ templates: message. ``field.is_hidden`` - This attribute is ``True`` is the form field is a hidden field and + This attribute is ``True`` if the form field is a hidden field and ``False`` otherwise. It's not particularly useful as a template variable, but could be useful in conditional tests such as::