Permalink
Browse files

Fixed broken links, round 4. refs #19516

  • Loading branch information...
1 parent 13a2b11 commit 067505ad19f088e8db1d8c788ceea388c7241bcd @timgraham timgraham committed Dec 29, 2012
@@ -27,6 +27,8 @@ use of the ``REMOTE_USER`` value using the ``RemoteUserMiddleware`` and
Configuration
=============
+.. class:: django.contrib.auth.middleware.RemoteUserMiddleware
+
First, you must add the
:class:`django.contrib.auth.middleware.RemoteUserMiddleware` to the
:setting:`MIDDLEWARE_CLASSES` setting **after** the
@@ -2,6 +2,8 @@
Writing custom django-admin commands
====================================
+.. module:: django.core.management
+
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``
@@ -261,6 +263,13 @@ the :meth:`~BaseCommand.handle` method must be implemented.
The actual logic of the command. Subclasses must implement this method.
+.. method:: BaseCommand.validate(app=None, display_num_errors=False)
+
+ Validates the given app, raising :class:`CommandError` for any errors.
+
+ If ``app`` is None, then all installed apps are validated.
+
+
.. _ref-basecommand-subclasses:
BaseCommand subclasses
@@ -153,8 +153,8 @@ class, from which everything is descended.
Initializing your new field is a matter of separating out any arguments that are
specific to your case from the common arguments and passing the latter to the
-:meth:`~django.db.models.Field.__init__` method of
-:class:`~django.db.models.Field` (or your parent class).
+``__init__()`` method of :class:`~django.db.models.Field` (or your parent
+class).
In our example, we'll call our field ``HandField``. (It's a good idea to call
your :class:`~django.db.models.Field` subclass ``<Something>Field``, so it's
@@ -602,11 +602,11 @@ Returns the default form field to use when this field is displayed in a model.
This method is called by the :class:`~django.forms.ModelForm` helper.
All of the ``kwargs`` dictionary is passed directly to the form field's
-:meth:`~django.forms.Field__init__` method. Normally, all you need to do is
-set up a good default for the ``form_class`` argument and then delegate further
-handling to the parent class. This might require you to write a custom form
-field (and even a form widget). See the :doc:`forms documentation
-</topics/forms/index>` for information about this, and take a look at the code in
+``__init__()`` method. Normally, all you need to do is set up a good default
+for the ``form_class`` argument and then delegate further handling to the
+parent class. This might require you to write a custom form field (and even a
+form widget). See the :doc:`forms documentation </topics/forms/index>` for
+information about this, and take a look at the code in
:mod:`django.contrib.localflavor` for some examples of custom widgets.
Continuing our ongoing example, we can write the :meth:`.formfield` method as::
@@ -668,7 +668,7 @@ Converting field data for serialization
.. method:: Field.value_to_string(self, obj)
This method is used by the serializers to convert the field into a string for
-output. Calling :meth:`Field._get_val_from_obj(obj)` is the best way to get the
+output. Calling ``Field._get_val_from_obj(obj)`` is the best way to get the
value to serialize. For example, since our ``HandField`` uses strings for its
data storage anyway, we can reuse some existing conversion code::
@@ -692,12 +692,12 @@ smoothly:
a field that's similar to what you want and extend it a little bit,
instead of creating an entirely new field from scratch.
-2. Put a :meth:`__str__` or :meth:`__unicode__` method on the class you're
+2. Put a ``__str__()`` or ``__unicode__()`` method on the class you're
wrapping up as a field. There are a lot of places where the default
behavior of the field code is to call
:func:`~django.utils.encoding.force_text` on the value. (In our
examples in this document, ``value`` would be a ``Hand`` instance, not a
- ``HandField``). So if your :meth:`__unicode__` method automatically
+ ``HandField``). So if your ``__unicode__()`` method automatically
converts to the string form of your Python object, you can save yourself
a lot of work.
@@ -20,7 +20,7 @@ these changes.
* The old imports for CSRF functionality (``django.contrib.csrf.*``),
which moved to core in 1.2, will be removed.
-* The :mod:`django.contrib.gis.db.backend` module will be removed in favor
+* The ``django.contrib.gis.db.backend`` module will be removed in favor
of the specific backends.
* ``SMTPConnection`` will be removed in favor of a generic Email backend API.
@@ -122,23 +122,23 @@ these changes.
The :attr:`~django.test.client.Response.templates` attribute should be
used instead.
-* The :class:`~django.test.simple.DjangoTestRunner` will be removed.
+* The ``django.test.simple.DjangoTestRunner`` will be removed.
Instead use a unittest-native class. The features of the
- :class:`django.test.simple.DjangoTestRunner` (including fail-fast and
+ ``django.test.simple.DjangoTestRunner`` (including fail-fast and
Ctrl-C test termination) can currently be provided by the unittest-native
- :class:`TextTestRunner`.
+ :class:`~unittest.TextTestRunner`.
* The undocumented function
- :func:`django.contrib.formtools.utils.security_hash` will be removed,
- instead use :func:`django.contrib.formtools.utils.form_hmac`
+ ``django.contrib.formtools.utils.security_hash`` will be removed,
+ instead use ``django.contrib.formtools.utils.form_hmac``
* The function-based generic view modules will be removed in favor of their
class-based equivalents, outlined :doc:`here
</topics/class-based-views/index>`.
-* The :class:`~django.core.servers.basehttp.AdminMediaHandler` will be
+* The ``django.core.servers.basehttp.AdminMediaHandler`` will be
removed. In its place use
- :class:`~django.contrib.staticfiles.handlers.StaticFilesHandler`.
+ ``django.contrib.staticfiles.handlers.StaticFilesHandler``.
* The template tags library ``adminmedia`` and the template tag ``{%
admin_media_prefix %}`` will be removed in favor of the generic static files
@@ -150,8 +150,7 @@ these changes.
an implied string. In 1.4, this behavior is provided by a version of the tag
in the ``future`` template tag library.
-* The :djadmin:`reset` and :djadmin:`sqlreset` management commands
- will be removed.
+* The ``reset`` and ``sqlreset`` management commands will be removed.
* Authentication backends will need to support an inactive user
being passed to all methods dealing with permissions.
@@ -162,11 +161,11 @@ these changes.
a :class:`~django.contrib.gis.geos.GEOSException` when called
on a geometry with no SRID value.
-* :class:`~django.http.CompatCookie` will be removed in favor of
- :class:`~django.http.SimpleCookie`.
+* ``django.http.CompatCookie`` will be removed in favor of
+ ``django.http.SimpleCookie``.
-* :class:`django.core.context_processors.PermWrapper` and
- :class:`django.core.context_processors.PermLookupDict` will be removed in
+* ``django.core.context_processors.PermWrapper`` and
+ ``django.core.context_processors.PermLookupDict`` will be removed in
favor of the corresponding
:class:`django.contrib.auth.context_processors.PermWrapper` and
:class:`django.contrib.auth.context_processors.PermLookupDict`,
@@ -213,8 +212,7 @@ these changes.
``django.utils.itercompat.all`` and ``django.utils.itercompat.any`` will
be removed. The Python builtin versions should be used instead.
-* The :func:`~django.views.decorators.csrf.csrf_response_exempt` and
- :func:`~django.views.decorators.csrf.csrf_view_exempt` decorators will
+* The ``csrf_response_exempt`` and ``csrf_view_exempt`` decorators will
be removed. Since 1.4 ``csrf_response_exempt`` has been a no-op (it
returns the same function), and ``csrf_view_exempt`` has been a
synonym for ``django.views.decorators.csrf.csrf_exempt``, which should
@@ -349,7 +349,7 @@ Login and logout signals
The auth framework uses two :doc:`signals </topics/signals>` that can be used
for notification when a user logs in or out.
-.. function:: django.contrib.auth.signals.user_logged_in
+.. function:: user_logged_in
Sent when a user logs in successfully.
@@ -364,7 +364,7 @@ for notification when a user logs in or out.
``user``
The user instance that just logged in.
-.. function:: django.contrib.auth.signals.user_logged_out
+.. function:: user_logged_out
Sent when the logout method is called.
@@ -379,9 +379,9 @@ for notification when a user logs in or out.
The user instance that just logged out or ``None`` if the
user was not authenticated.
-.. function:: django.contrib.auth.signals.user_login_failed
+.. function:: user_login_failed
-.. versionadded:: 1.5
+ .. versionadded:: 1.5
Sent when the user failed to login successfully
@@ -140,6 +140,8 @@ with the rest of :ref:`Django's unit tests <running-unit-tests>`.
Run only GeoDjango tests
------------------------
+.. class:: django.contrib.gis.tests.GeoDjangoTestSuiteRunner
+
To run *only* the tests for GeoDjango, the :setting:`TEST_RUNNER`
setting must be changed to use the
:class:`~django.contrib.gis.tests.GeoDjangoTestSuiteRunner`::
@@ -149,6 +149,8 @@ tags for the levels you wish to override::
Using messages in views and templates
=====================================
+.. function:: add_message(request, level, message, extra_tags='', fail_silently=False)
+
Adding a message
----------------
View
@@ -27,9 +27,8 @@ module system.
.. warning::
Many of these signals are sent by various model methods like
- :meth:`~django.db.models.Model.__init__` or
- :meth:`~django.db.models.Model.save` that you can overwrite in your own
- code.
+ ``__init__()`` or :meth:`~django.db.models.Model.save` that you can
+ override in your own code.
If you override these methods on your model, you must call the parent class'
methods for this signals to be sent.
@@ -47,20 +46,18 @@ pre_init
.. ^^^^^^^ this :module: hack keeps Sphinx from prepending the module.
Whenever you instantiate a Django model, this signal is sent at the beginning
-of the model's :meth:`~django.db.models.Model.__init__` method.
+of the model's ``__init__()`` method.
Arguments sent with this signal:
``sender``
The model class that just had an instance created.
``args``
- A list of positional arguments passed to
- :meth:`~django.db.models.Model.__init__`:
+ A list of positional arguments passed to ``__init__()``:
``kwargs``
- A dictionary of keyword arguments passed to
- :meth:`~django.db.models.Model.__init__`:.
+ A dictionary of keyword arguments passed to ``__init__()``:
For example, the :doc:`tutorial </intro/tutorial01>` has this line::
@@ -74,7 +71,7 @@ Argument Value
``sender`` ``Poll`` (the class itself)
``args`` ``[]`` (an empty list because there were no positional
- arguments passed to ``__init__``.)
+ arguments passed to ``__init__()``.)
``kwargs`` ``{'question': "What's up?", 'pub_date': datetime.now()}``
========== ===============================================================
@@ -85,7 +82,7 @@ post_init
.. data:: django.db.models.signals.post_init
:module:
-Like pre_init, but this one is sent when the :meth:`~django.db.models.Model.__init__`: method finishes.
+Like pre_init, but this one is sent when the ``__init__()`` method finishes.
Arguments sent with this signal:
@@ -277,8 +277,9 @@ Handle uploaded files using the new API
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Replace use of uploaded files -- that is, entries in ``request.FILES`` -- as
-simple dictionaries with the new :class:`~django.core.files.UploadedFile`. The
-old dictionary syntax no longer works.
+simple dictionaries with the new
+:class:`~django.core.files.uploadedfile.UploadedFile`. The old dictionary
+syntax no longer works.
Thus, in a view like::
@@ -410,7 +411,7 @@ U.S. local flavor
~~~~~~~~~~~~~~~~~
``django.contrib.localflavor.usa`` has been renamed to
-:mod:`django.contrib.localflavor.us`. This change was made to match the naming
+``django.contrib.localflavor.us``. This change was made to match the naming
scheme of other local flavors. To migrate your code, all you need to do is
change the imports.
@@ -642,8 +643,8 @@ The generic relation classes -- ``GenericForeignKey`` and ``GenericRelation``
Testing
-------
-:meth:`django.test.Client.login` has changed
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+:meth:`django.test.client.Client.login` has changed
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Old (0.96)::
@@ -721,7 +722,7 @@ To update your code:
1. Use :class:`django.utils.datastructures.SortedDict` wherever you were
using ``django.newforms.forms.SortedDictFromList``.
-2. Because :meth:`django.utils.datastructures.SortedDict.copy` doesn't
+2. Because ``django.utils.datastructures.SortedDict.copy`` doesn't
return a deepcopy as ``SortedDictFromList.copy()`` did, you will need
to update your code if you were relying on a deepcopy. Do this by using
``copy.deepcopy`` directly.
@@ -36,7 +36,7 @@ A number of features have been added to Django's model layer:
You can now control whether or not Django creates database tables for a model
using the :attr:`~Options.managed` model option. This defaults to ``True``,
meaning that Django will create the appropriate database tables in
-:djadmin:`syncdb` and remove them as part of :djadmin:`reset` command. That
+:djadmin:`syncdb` and remove them as part of ``reset`` command. That
is, Django *manages* the database table's lifecycle.
If you set this to ``False``, however, no database table creating or deletion
View
@@ -37,7 +37,7 @@ If you are using a 32-bit platform, you're off the hook; you'll observe no
differences as a result of this change.
However, **users on 64-bit platforms may experience some problems** using the
-:djadmin:`reset` management command. Prior to this change, 64-bit platforms
+``reset`` management command. Prior to this change, 64-bit platforms
would generate a 64-bit, 16 character digest in the constraint name; for
example::
@@ -48,14 +48,14 @@ Following this change, all platforms, regardless of word size, will generate a
ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_32091d1e FOREIGN KEY ...
-As a result of this change, you will not be able to use the :djadmin:`reset`
+As a result of this change, you will not be able to use the ``reset``
management command on any table made by a 64-bit machine. This is because the
the new generated name will not match the historically generated name; as a
result, the SQL constructed by the reset command will be invalid.
If you need to reset an application that was created with 64-bit constraints,
you will need to manually drop the old constraint prior to invoking
-:djadmin:`reset`.
+``reset``.
Test cases are now run in a transaction
---------------------------------------
@@ -120,9 +120,8 @@ has been saved.
Changes to how model formsets are saved
---------------------------------------
-.. currentmodule:: django.forms.models
-
-In Django 1.1, :class:`BaseModelFormSet` now calls :meth:`ModelForm.save()`.
+In Django 1.1, :class:`~django.forms.models.BaseModelFormSet` now calls
+``ModelForm.save()``.
This is backwards-incompatible if you were modifying ``self.initial`` in a model
formset's ``__init__``, or if you relied on the internal ``_total_form_count``
@@ -146,7 +145,7 @@ Permanent redirects and the ``redirect_to()`` generic view
----------------------------------------------------------
Django 1.1 adds a ``permanent`` argument to the
-:func:`django.views.generic.simple.redirect_to()` view. This is technically
+``django.views.generic.simple.redirect_to()`` view. This is technically
backwards-incompatible if you were using the ``redirect_to`` view with a
format-string key called 'permanent', which is highly unlikely.
@@ -211,8 +210,8 @@ Query expressions
Queries can now refer to a another field on the query and can traverse
relationships to refer to fields on related models. This is implemented in the
-new :class:`F` object; for full details, including examples, consult the
-:ref:`documentation for F expressions <query-expressions>`.
+new :class:`~django.db.models.F` object; for full details, including examples,
+consult the :ref:`documentation for F expressions <query-expressions>`.
Model improvements
------------------
@@ -225,7 +224,7 @@ A number of features have been added to Django's model layer:
You can now control whether or not Django manages the life-cycle of the database
tables for a model using the :attr:`~Options.managed` model option. This
defaults to ``True``, meaning that Django will create the appropriate database
-tables in :djadmin:`syncdb` and remove them as part of the :djadmin:`reset`
+tables in :djadmin:`syncdb` and remove them as part of the ``reset``
command. That is, Django *manages* the database table's lifecycle.
If you set this to ``False``, however, no database table creating or deletion
@@ -76,7 +76,7 @@ GeoDjango
=========
The function-based :setting:`TEST_RUNNER` previously used to execute
-the GeoDjango test suite, :func:`django.contrib.gis.tests.run_gis_tests`,
+the GeoDjango test suite, ``django.contrib.gis.tests.run_gis_tests``,
was finally deprecated in favor of a class-based test runner,
:class:`django.contrib.gis.tests.GeoDjangoTestSuiteRunner`, added in this
release.
Oops, something went wrong.

0 comments on commit 067505a

Please sign in to comment.