Fixed #2845 -- Corrected a few spelling errors in the docs and changed a
couple of correctly spelt words to their North American counterparts for consistency. Thanks, treborhudson@gmail.com git-svn-id: http://code.djangoproject.com/svn/django/trunk@3883 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
7d5f6fe0f4
commit
fa8a1d252a
|
@ -82,7 +82,7 @@ There are also a few styles for styling text.
|
||||||
.help
|
.help
|
||||||
This is a custom class for blocks of inline help text explaining the
|
This is a custom class for blocks of inline help text explaining the
|
||||||
function of form elements. It makes text smaller and gray, and when applied
|
function of form elements. It makes text smaller and gray, and when applied
|
||||||
to ``p`` elements withing ``.form-row`` elements (see Form Styles below),
|
to ``p`` elements within ``.form-row`` elements (see Form Styles below),
|
||||||
it will offset the text to align with the form field. Use this for help
|
it will offset the text to align with the form field. Use this for help
|
||||||
text, instead of ``small quiet``. It works on other elements, but try to
|
text, instead of ``small quiet``. It works on other elements, but try to
|
||||||
put the class on a ``p`` whenever you can.
|
put the class on a ``p`` whenever you can.
|
||||||
|
|
|
@ -82,7 +82,7 @@ that 90% of Django can be considered forwards-compatible at this point.
|
||||||
That said, these APIs should *not* be considered stable, and are likely to
|
That said, these APIs should *not* be considered stable, and are likely to
|
||||||
change:
|
change:
|
||||||
|
|
||||||
- `Forms and validation`_ will most likely be compeltely rewritten to
|
- `Forms and validation`_ will most likely be completely rewritten to
|
||||||
deemphasize Manipulators in favor of validation-aware models.
|
deemphasize Manipulators in favor of validation-aware models.
|
||||||
|
|
||||||
- `Serialization`_ is under heavy development; changes are likely.
|
- `Serialization`_ is under heavy development; changes are likely.
|
||||||
|
@ -91,7 +91,7 @@ change:
|
||||||
API changes may be necessary.
|
API changes may be necessary.
|
||||||
|
|
||||||
- Generic relations will most likely be moved out of core and into the
|
- Generic relations will most likely be moved out of core and into the
|
||||||
content-types contrib package to avoid core dependacies on optional
|
content-types contrib package to avoid core dependancies on optional
|
||||||
components.
|
components.
|
||||||
|
|
||||||
- The comments framework, which is yet undocumented, will likely get a complete
|
- The comments framework, which is yet undocumented, will likely get a complete
|
||||||
|
|
|
@ -499,7 +499,7 @@ specify an object to edit or delete.
|
||||||
How do I add database-specific options to my CREATE TABLE statements, such as specifying MyISAM as the table type?
|
How do I add database-specific options to my CREATE TABLE statements, such as specifying MyISAM as the table type?
|
||||||
------------------------------------------------------------------------------------------------------------------
|
------------------------------------------------------------------------------------------------------------------
|
||||||
|
|
||||||
We try to avoid adding special cases in the Django code to accomodate all the
|
We try to avoid adding special cases in the Django code to accommodate all the
|
||||||
database-specific options such as table type, etc. If you'd like to use any of
|
database-specific options such as table type, etc. If you'd like to use any of
|
||||||
these options, create an `SQL initial data file`_ that contains ``ALTER TABLE``
|
these options, create an `SQL initial data file`_ that contains ``ALTER TABLE``
|
||||||
statements that do what you want to do. The initial data files are executed in
|
statements that do what you want to do. The initial data files are executed in
|
||||||
|
|
|
@ -489,7 +489,7 @@ required fields are present and non-empty. For each field that passes that
|
||||||
test *and if the form submission contained data* for that field, all the
|
test *and if the form submission contained data* for that field, all the
|
||||||
validators for that field are called in turn. The emphasized portion in the
|
validators for that field are called in turn. The emphasized portion in the
|
||||||
last sentence is important: if a form field is not submitted (because it
|
last sentence is important: if a form field is not submitted (because it
|
||||||
contains no data -- which is normal HTML behaviour), the validators are not
|
contains no data -- which is normal HTML behavior), the validators are not
|
||||||
run against the field.
|
run against the field.
|
||||||
|
|
||||||
This feature is particularly important for models using
|
This feature is particularly important for models using
|
||||||
|
|
|
@ -1056,7 +1056,7 @@ Formats a date as the time since that date (i.e. "4 days, 6 hours").
|
||||||
Takes an optional argument that is a variable containing the date to use as
|
Takes an optional argument that is a variable containing the date to use as
|
||||||
the comparison point (without the argument, the comparison point is *now*).
|
the comparison point (without the argument, the comparison point is *now*).
|
||||||
For example, if ``blog_date`` is a date instance representing midnight on 1
|
For example, if ``blog_date`` is a date instance representing midnight on 1
|
||||||
June 2006, and ``comment_date`` is a date instanace for 08:00 on 1 June 2006,
|
June 2006, and ``comment_date`` is a date instance for 08:00 on 1 June 2006,
|
||||||
then ``{{ comment_date|timesince:blog_date }}`` would return "8 hours".
|
then ``{{ comment_date|timesince:blog_date }}`` would return "8 hours".
|
||||||
|
|
||||||
timeuntil
|
timeuntil
|
||||||
|
|
|
@ -817,7 +817,7 @@ Inclusion tags
|
||||||
|
|
||||||
Another common type of template tag is the type that displays some data by
|
Another common type of template tag is the type that displays some data by
|
||||||
rendering *another* template. For example, Django's admin interface uses custom
|
rendering *another* template. For example, Django's admin interface uses custom
|
||||||
template tags to display the buttons along the botton of the "add/change" form
|
template tags to display the buttons along the bottom of the "add/change" form
|
||||||
pages. Those buttons always look the same, but the link targets change depending
|
pages. Those buttons always look the same, but the link targets change depending
|
||||||
on the object being edited -- so they're a perfect case for using a small
|
on the object being edited -- so they're a perfect case for using a small
|
||||||
template that is filled with details from the current object. (In the admin's
|
template that is filled with details from the current object. (In the admin's
|
||||||
|
|
|
@ -389,7 +389,7 @@ an alternative framework as if they were normal Django tests.
|
||||||
|
|
||||||
When you run ``./manage.py test``, Django looks at the ``TEST_RUNNER``
|
When you run ``./manage.py test``, Django looks at the ``TEST_RUNNER``
|
||||||
setting to determine what to do. By default, ``TEST_RUNNER`` points to ``django.test.simple.run_tests``. This method defines the default Django
|
setting to determine what to do. By default, ``TEST_RUNNER`` points to ``django.test.simple.run_tests``. This method defines the default Django
|
||||||
testing behaviour. This behaviour involves:
|
testing behavior. This behavior involves:
|
||||||
|
|
||||||
#. Performing global pre-test setup
|
#. Performing global pre-test setup
|
||||||
#. Creating the test database
|
#. Creating the test database
|
||||||
|
@ -435,7 +435,7 @@ a number of utility methods in the ``django.test.utils`` module.
|
||||||
``create_test_db(verbosity=1, autoclobber=False)``
|
``create_test_db(verbosity=1, autoclobber=False)``
|
||||||
Creates a new test database, and run ``syncdb`` against it.
|
Creates a new test database, and run ``syncdb`` against it.
|
||||||
|
|
||||||
``verbosity`` has the same behaviour as in the test runner.
|
``verbosity`` has the same behavior as in the test runner.
|
||||||
|
|
||||||
``Autoclobber`` describes the behavior that will occur if a database with
|
``Autoclobber`` describes the behavior that will occur if a database with
|
||||||
the same name as the test database is discovered. If ``autoclobber`` is False,
|
the same name as the test database is discovered. If ``autoclobber`` is False,
|
||||||
|
@ -450,4 +450,4 @@ a number of utility methods in the ``django.test.utils`` module.
|
||||||
Destroys the database with the name ``settings.DATABASE_NAME`` matching,
|
Destroys the database with the name ``settings.DATABASE_NAME`` matching,
|
||||||
and restores the value of ``settings.DATABASE_NAME`` to the provided name.
|
and restores the value of ``settings.DATABASE_NAME`` to the provided name.
|
||||||
|
|
||||||
``verbosity`` has the same behaviour as in the test runner.
|
``verbosity`` has the same behavior as in the test runner.
|
||||||
|
|
|
@ -91,7 +91,7 @@ Finally, it calls that ``detail()`` function like so::
|
||||||
The ``poll_id='23'`` part comes from ``(?P<poll_id>\d+)``. Using parenthesis around a
|
The ``poll_id='23'`` part comes from ``(?P<poll_id>\d+)``. Using parenthesis around a
|
||||||
pattern "captures" the text matched by that pattern and sends it as an argument
|
pattern "captures" the text matched by that pattern and sends it as an argument
|
||||||
to the view function; the ``?P<poll_id>`` defines the name that will be used to
|
to the view function; the ``?P<poll_id>`` defines the name that will be used to
|
||||||
identify the matched pattern; and ``\d+`` is a regular experession to match a sequence of
|
identify the matched pattern; and ``\d+`` is a regular expression to match a sequence of
|
||||||
digits (i.e., a number).
|
digits (i.e., a number).
|
||||||
|
|
||||||
Because the URL patterns are regular expressions, there really is no limit on
|
Because the URL patterns are regular expressions, there really is no limit on
|
||||||
|
|
Loading…
Reference in New Issue