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
This commit is contained in:
parent
184ea1c91f
commit
7372ea159a
|
@ -76,7 +76,7 @@ def validate(cls, model):
|
||||||
field = opts.get_field_by_name(field_name)[0]
|
field = opts.get_field_by_name(field_name)[0]
|
||||||
except models.FieldDoesNotExist:
|
except models.FieldDoesNotExist:
|
||||||
raise ImproperlyConfigured("'%s.list_editable[%d]' refers to a "
|
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__))
|
% (cls.__name__, idx, field_name, model.__name__))
|
||||||
if field_name not in cls.list_display:
|
if field_name not in cls.list_display:
|
||||||
raise ImproperlyConfigured("'%s.list_editable[%d]' refers to "
|
raise ImproperlyConfigured("'%s.list_editable[%d]' refers to "
|
||||||
|
|
|
@ -254,7 +254,7 @@ called when the attribute is initialized.
|
||||||
Useful methods
|
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,
|
the ``__metaclass__``, you might consider overriding a few standard methods,
|
||||||
depending on your field's behavior. The list of methods below is in
|
depending on your field's behavior. The list of methods below is in
|
||||||
approximately decreasing order of importance, so start from the top.
|
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
|
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
|
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
|
shouldn't need to implement this method unless your custom field needs a
|
||||||
conversion when being saved that is not the same as the used for normal query
|
special conversion when being saved that is not the same as the conversion used
|
||||||
parameters (which is implemented by ``get_db_prep_value``).
|
for normal query parameters (which is implemented by ``get_db_prep_value``).
|
||||||
|
|
||||||
Preprocessing values before saving
|
Preprocessing values before saving
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
@ -522,7 +522,7 @@ Continuing our ongoing example, we can write the :meth:`formfield` method as::
|
||||||
defaults.update(kwargs)
|
defaults.update(kwargs)
|
||||||
return super(HandField, self).formfield(**defaults)
|
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
|
default widget). This document doesn't cover the details of writing custom form
|
||||||
fields.
|
fields.
|
||||||
|
|
||||||
|
|
|
@ -1,8 +1,8 @@
|
||||||
.. _howto-deployment-fastcgi:
|
.. _howto-deployment-fastcgi:
|
||||||
|
|
||||||
===========================================
|
============================================
|
||||||
How to use Django with FastCGI, SCGI or AJP
|
How to use Django with FastCGI, SCGI, or AJP
|
||||||
===========================================
|
============================================
|
||||||
|
|
||||||
.. highlight:: bash
|
.. 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
|
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
|
the URLs under ``'/'`` and you wanted to use this setting, you would set
|
||||||
``FORCE_SCRIPT_NAME = ''`` in your settings file.
|
``FORCE_SCRIPT_NAME = ''`` in your settings file.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -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
|
Django requires Apache 2.x and mod_python 3.x, and you should use Apache's
|
||||||
`prefork MPM`_, as opposed to the `worker MPM`_.
|
`prefork MPM`_, as opposed to the `worker MPM`_.
|
||||||
|
|
||||||
You may also be interested in :ref:`How to use Django with FastCGI, SCGI or AJP
|
You may also be interested in :ref:`How to use Django with FastCGI, SCGI, or
|
||||||
<howto-deployment-fastcgi>` (which also covers SCGI and AJP).
|
AJP <howto-deployment-fastcgi>`.
|
||||||
|
|
||||||
.. _Apache: http://httpd.apache.org/
|
.. _Apache: http://httpd.apache.org/
|
||||||
.. _mod_python: http://www.modpython.org/
|
.. _mod_python: http://www.modpython.org/
|
||||||
|
@ -361,5 +361,3 @@ as necessary.
|
||||||
.. _Expat Causing Apache Crash: http://www.dscpl.com.au/articles/modpython-006.html
|
.. _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
|
.. _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
|
.. _Getting mod_python Working: http://www.dscpl.com.au/articles/modpython-001.html
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -170,14 +170,14 @@ with the timestamp and username of the person who made the change:
|
||||||
Customize the admin form
|
Customize the admin form
|
||||||
========================
|
========================
|
||||||
|
|
||||||
Take a few minutes to marvel at all the code you didn't have to write. When you
|
Take a few minutes to marvel at all the code you didn't have to write. By
|
||||||
call ``admin.site.register(Poll)``, Django just lets you edit the object and
|
registering the Poll model with ``admin.site.register(Poll)``, Django was able
|
||||||
"guess" at how to display it within the admin. Often you'll want to control how
|
to construct a default form representation. Often, you'll want to customize how
|
||||||
the admin looks and works. You'll do this by telling Django about the options
|
the admin form looks and works. You'll do this by telling Django the options
|
||||||
you want when you register the object.
|
you want when you register the object.
|
||||||
|
|
||||||
Let's see how this works by reordering the fields on the edit form. Replace the
|
Let's see how this works by re-ordering the fields on the edit form. Replace
|
||||||
``admin.site.register(Poll)`` line with::
|
the ``admin.site.register(Poll)`` line with::
|
||||||
|
|
||||||
class PollAdmin(admin.ModelAdmin):
|
class PollAdmin(admin.ModelAdmin):
|
||||||
fields = ['pub_date', 'question']
|
fields = ['pub_date', 'question']
|
||||||
|
|
|
@ -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
|
A list of actions to make available on the change list page. See
|
||||||
:ref:`ref-contrib-admin-actions` for details.
|
: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
|
Controls where on the page the actions bar appears. By default, the admin
|
||||||
|
|
|
@ -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
|
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
|
`Release 8.2.5`_ or later. Django will raise a ``NotImplementedError`` if you
|
||||||
attempt to use the ``StdDev(sample=False)`` or ``Variance(sample=False)``
|
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
|
.. _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
|
.. _Release 8.2.5: http://developer.postgresql.org/pgdocs/postgres/release-8-2-5.html
|
||||||
|
@ -35,7 +35,7 @@ Transaction handling
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
:ref:`By default <topics-db-transactions>`, Django starts a transaction when a
|
:ref:`By default <topics-db-transactions>`, 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
|
request/response handling. The PostgreSQL backends normally operate the same
|
||||||
as any other Django backend in this respect.
|
as any other Django backend in this respect.
|
||||||
|
|
||||||
|
@ -87,8 +87,8 @@ MySQL notes
|
||||||
===========
|
===========
|
||||||
|
|
||||||
Django expects the database to support transactions, referential integrity,
|
Django expects the database to support transactions, referential integrity,
|
||||||
and Unicode support (UTF-8 encoding). Fortunately, MySQL_ has all these
|
and Unicode (UTF-8 encoding). Fortunately, MySQL_ has all these
|
||||||
features as available as far back as 3.23. While it may be possible to use
|
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.
|
3.23 or 4.0, you'll probably have less trouble if you use 4.1 or 5.0.
|
||||||
|
|
||||||
MySQL 4.1
|
MySQL 4.1
|
||||||
|
|
|
@ -18,12 +18,13 @@ Throughout this reference we'll use the :ref:`example weblog models
|
||||||
Creating objects
|
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)
|
.. class:: Model(**kwargs)
|
||||||
|
|
||||||
The keyword arguments to are simply the names of the fields you've defined on
|
The keyword arguments are simply the names of the fields you've defined on your
|
||||||
your model. Note that instantiating a model in no way touches your database; for
|
model. Note that instantiating a model in no way touches your database; for
|
||||||
that, you need to ``save()``.
|
that, you need to ``save()``.
|
||||||
|
|
||||||
Saving objects
|
Saving objects
|
||||||
|
|
|
@ -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
|
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.
|
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,
|
When specifying the field to be aggregated in an aggregate function, Django
|
||||||
Django will allow you to use the same
|
will allow you to use the same :ref:`double underscore notation
|
||||||
:ref:`double underscore notation <field-lookups-intro>` that is used
|
<field-lookups-intro>` that is used when referring to related fields in
|
||||||
when referring to related fields in filters. Django will then handle
|
filters. Django will then handle any table joins that are required to retrieve
|
||||||
any table joins that are required to retrieve and aggregate the
|
and aggregate the related value.
|
||||||
related value.
|
|
||||||
|
|
||||||
For example, to find the price range of books offered in each store,
|
For example, to find the price range of books offered in each store,
|
||||||
you could use the annotation::
|
you could use the annotation::
|
||||||
|
|
|
@ -1019,10 +1019,11 @@ ordering or the default manager in the proxy, without having to alter the
|
||||||
original.
|
original.
|
||||||
|
|
||||||
Proxy models are declared like normal models. You tell Django that it's a
|
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
|
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
|
from django.contrib.auth.models import User
|
||||||
|
|
||||||
|
|
|
@ -293,7 +293,7 @@ templates:
|
||||||
message.
|
message.
|
||||||
|
|
||||||
``field.is_hidden``
|
``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
|
``False`` otherwise. It's not particularly useful as a template
|
||||||
variable, but could be useful in conditional tests such as::
|
variable, but could be useful in conditional tests such as::
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue