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:
Gary Wilson Jr
parent
184ea1c91f
commit
7372ea159a
|
|
@ -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 "
|
||||
|
|
|
|||
|
|
@ -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
|
||||
<topics-serialization>`. 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
<howto-deployment-fastcgi>` (which also covers SCGI and AJP).
|
||||
You may also be interested in :ref:`How to use Django with FastCGI, SCGI, or
|
||||
AJP <howto-deployment-fastcgi>`.
|
||||
|
||||
.. _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
|
||||
</Location>
|
||||
|
||||
|
|
@ -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"**
|
||||
</Location>
|
||||
|
|
@ -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
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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']
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 <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
|
||||
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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 <field-lookups-intro>` 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
|
||||
<field-lookups-intro>` 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::
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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::
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue