[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.
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
parent
9d808c14a5
commit
68aa33f901
|
|
@ -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
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -167,14 +167,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']
|
||||
|
|
|
|||
|
|
@ -19,8 +19,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
|
||||
|
|
|
|||
Loading…
Reference in New Issue