mirror of
https://github.com/django/django.git
synced 2025-10-24 06:06:09 +00:00
[soc2010/query-refactor] Merged up to trunk r13328.
git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2010/query-refactor@13329 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
@@ -8,7 +8,7 @@ Writing custom django-admin commands
|
||||
|
||||
Applications can register their own actions with ``manage.py``. For example,
|
||||
you might want to add a ``manage.py`` action for a Django app that you're
|
||||
distributing. In this document, we will be building a custom ``closepoll``
|
||||
distributing. In this document, we will be building a custom ``closepoll``
|
||||
command for the ``polls`` application from the
|
||||
:ref:`tutorial<intro-tutorial01>`.
|
||||
|
||||
@@ -62,9 +62,16 @@ look like this:
|
||||
poll.opened = False
|
||||
poll.save()
|
||||
|
||||
print 'Successfully closed poll "%s"' % poll_id
|
||||
self.stdout.write('Successfully closed poll "%s"\n' % poll_id)
|
||||
|
||||
The new custom command can be called using ``python manage.py closepoll
|
||||
.. note::
|
||||
When you are using management commands and wish to provide console
|
||||
output, you should write to ``self.stdout`` and ``self.stderr``,
|
||||
instead of printing to ``stdout`` and ``stderr`` directly. By
|
||||
using these proxies, it becomes much easier to test your custom
|
||||
command.
|
||||
|
||||
The new custom command can be called using ``python manage.py closepoll
|
||||
<poll_id>``.
|
||||
|
||||
The ``handle()`` method takes zero or more ``poll_ids`` and sets ``poll.opened``
|
||||
@@ -91,8 +98,8 @@ must be added to :attr:`~BaseCommand.option_list` like this:
|
||||
)
|
||||
# ...
|
||||
|
||||
In addition to being able to add custom command line options, all
|
||||
:ref:`management commands<ref-django-admin>` can accept some
|
||||
In addition to being able to add custom command line options, all
|
||||
:ref:`management commands<ref-django-admin>` can accept some
|
||||
default options such as :djadminopt:`--verbosity` and :djadminopt:`--traceback`.
|
||||
|
||||
Command objects
|
||||
@@ -113,7 +120,7 @@ Subclassing the :class:`BaseCommand` class requires that you implement the
|
||||
Attributes
|
||||
----------
|
||||
|
||||
All attributes can be set in your derived class and can be used in
|
||||
All attributes can be set in your derived class and can be used in
|
||||
:class:`BaseCommand`'s :ref:`subclasses<ref-basecommand-subclasses>`.
|
||||
|
||||
.. attribute:: BaseCommand.args
|
||||
@@ -133,7 +140,7 @@ All attributes can be set in your derived class and can be used in
|
||||
.. attribute:: BaseCommand.help
|
||||
|
||||
A short description of the command, which will be printed in the
|
||||
help message when the user runs the command
|
||||
help message when the user runs the command
|
||||
``python manage.py help <command>``.
|
||||
|
||||
.. attribute:: BaseCommand.option_list
|
||||
@@ -230,7 +237,7 @@ Rather than implementing :meth:`~BaseCommand.handle`, subclasses must implement
|
||||
A command which takes no arguments on the command line.
|
||||
|
||||
Rather than implementing :meth:`~BaseCommand.handle`, subclasses must implement
|
||||
:meth:`~NoArgsCommand.handle_noargs`; :meth:`~BaseCommand.handle` itself is
|
||||
:meth:`~NoArgsCommand.handle_noargs`; :meth:`~BaseCommand.handle` itself is
|
||||
overridden to ensure no arguments are passed to the command.
|
||||
|
||||
.. method:: NoArgsCommand.handle_noargs(**options)
|
||||
|
||||
@@ -1189,7 +1189,7 @@ your admin page for managing the relation.
|
||||
|
||||
In all other respects, the ``InlineModelAdmin`` is exactly the same as any
|
||||
other. You can customize the appearance using any of the normal
|
||||
``InlineModelAdmin`` properties.
|
||||
``ModelAdmin`` properties.
|
||||
|
||||
Working with Many-to-Many Intermediary Models
|
||||
----------------------------------------------
|
||||
|
||||
@@ -441,7 +441,7 @@ to be displayed.
|
||||
|
||||
See also ``DATETIME_INPUT_FORMATS`` and ``TIME_INPUT_FORMATS``.
|
||||
|
||||
.. _datetime: http://docs.python.org/library/datetime.html#strftime-behavior
|
||||
.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior
|
||||
|
||||
.. setting:: DATETIME_FORMAT
|
||||
|
||||
@@ -481,7 +481,7 @@ to be displayed.
|
||||
|
||||
See also ``DATE_INPUT_FORMATS`` and ``TIME_INPUT_FORMATS``.
|
||||
|
||||
.. _datetime: http://docs.python.org/library/datetime.html#strftime-behavior
|
||||
.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior
|
||||
|
||||
.. setting:: DEBUG
|
||||
|
||||
@@ -494,8 +494,9 @@ A boolean that turns on/off debug mode.
|
||||
|
||||
If you define custom settings, `django/views/debug.py`_ has a ``HIDDEN_SETTINGS``
|
||||
regular expression which will hide from the DEBUG view anything that contains
|
||||
``'SECRET'``, ``'PASSWORD'``, or ``'PROFANITIES'``. This allows untrusted users to
|
||||
be able to give backtraces without seeing sensitive (or offensive) settings.
|
||||
``'SECRET'``, ``'PASSWORD'``, ``'PROFANITIES'``, or ``'SIGNATURE'``. This allows
|
||||
untrusted users to be able to give backtraces without seeing sensitive (or
|
||||
offensive) settings.
|
||||
|
||||
Still, note that there are always going to be sections of your debug output that
|
||||
are inappropriate for public consumption. File paths, configuration options, and
|
||||
@@ -615,7 +616,7 @@ EMAIL_BACKEND
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
Default: ``'django.core.mail.backends.smtp'``
|
||||
Default: ``'django.core.mail.backends.smtp.EmailBackend'``
|
||||
|
||||
The backend to use for sending emails. For the list of available backends see
|
||||
:ref:`topics-email`.
|
||||
@@ -1531,7 +1532,7 @@ to be displayed.
|
||||
|
||||
See also ``DATE_INPUT_FORMATS`` and ``DATETIME_INPUT_FORMATS``.
|
||||
|
||||
.. _datetime: http://docs.python.org/library/datetime.html#strftime-behavior
|
||||
.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior
|
||||
|
||||
.. setting:: TIME_ZONE
|
||||
|
||||
|
||||
@@ -1248,6 +1248,19 @@ cause of an failure in your test suite.
|
||||
``target_status_code`` will be the url and status code for the final
|
||||
point of the redirect chain.
|
||||
|
||||
.. method:: TestCase.assertQuerysetEqual(response, qs, values, transform=repr)
|
||||
|
||||
Asserts that a queryset ``qs`` returns a particular list of values ``values``.
|
||||
|
||||
The comparison of the contents of ``qs`` and ``values`` is performed using
|
||||
the function ``transform``; by default, this means that the ``repr()`` of
|
||||
each value is compared. Any other callable can be used if ``repr()`` doesn't
|
||||
provide a unique or helpful comparison.
|
||||
|
||||
The comparison is also ordering dependent. If ``qs`` doesn't provide an
|
||||
implicit ordering, you will need to apply a ``order_by()`` clause to your
|
||||
queryset to ensure that the test will pass reliably.
|
||||
|
||||
.. _topics-testing-email:
|
||||
|
||||
E-mail services
|
||||
|
||||
Reference in New Issue
Block a user