Django/django
11
0
Fork 0
Code Pull Requests Projects Releases Activity

[1.0.X]: 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.

Browse Source 
Backport of r10242 from trunk.


git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@10243 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Gary Wilson Jr 2009-03-31 07:16:25 +00:00
parent 9d808c14a5
commit 68aa33f901
6 changed files with 28 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/howto/custom-model-fields.txt
View File

@ -45,7 +45,7 @@ something like this::
self.east = east self.east = east
self.south = south self.south = south
self.west = west self.west = west
# ... (other possibly useful methods omitted) ... # ... (other possibly useful methods omitted) ...
.. _Bridge: http://en.wikipedia.org/wiki/Contract_bridge .. _Bridge: http://en.wikipedia.org/wiki/Contract_bridge
@ -203,7 +203,7 @@ parameters:
:class:`ForeignKey`). For advanced use only. :class:`ForeignKey`). For advanced use only.
* :attr:`~django.db.models.Field.default` * :attr:`~django.db.models.Field.default`
* :attr:`~django.db.models.Field.editable` * :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 not be serialized when the model is passed to Django's :ref:`serializers
<topics-serialization>`. Defaults to ``True``. <topics-serialization>`. Defaults to ``True``.
* :attr:`~django.db.models.Field.prepopulate_from` * :attr:`~django.db.models.Field.prepopulate_from`
@ -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.

8
docs/howto/deployment/fastcgi.txt
View File

@ -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.

14
docs/howto/deployment/modpython.txt
View 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/
@ -38,7 +38,7 @@ Then edit your ``httpd.conf`` file and add the following::
SetHandler python-program SetHandler python-program
PythonHandler django.core.handlers.modpython PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE mysite.settings SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonOption django.root /mysite PythonOption django.root /mysite
PythonDebug On PythonDebug On
</Location> </Location>
@ -84,7 +84,7 @@ computer, you'll have to tell mod_python where your project can be found:
SetHandler python-program SetHandler python-program
PythonHandler django.core.handlers.modpython PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE mysite.settings SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonOption django.root /mysite PythonOption django.root /mysite
PythonDebug On PythonDebug On
**PythonPath "['/path/to/project'] + sys.path"** **PythonPath "['/path/to/project'] + sys.path"**
</Location> </Location>
@ -273,7 +273,7 @@ Here are two recommended approaches:
document root. This way, all of your Django-related files -- code **and** 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 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. 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 2. Or, copy the admin media files so that they live within your Apache
document root. 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, 1. It may be because your Python code is importing the "pyexpat" module,
which may conflict with the version embedded in Apache. For full which may conflict with the version embedded in Apache. For full
information, see `Expat Causing Apache Crash`_. information, see `Expat Causing Apache Crash`_.
2. It may be because you're running mod_python and mod_php in the same 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, 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 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 .. _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

12
docs/intro/tutorial02.txt
View File

@ -167,14 +167,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']

4
docs/ref/databases.txt
View File

@ -19,8 +19,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

7
docs/ref/models/instances.txt
View File

@ -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