diff options
Diffstat (limited to 'docs/ref')
| -rw-r--r-- | docs/ref/contrib/admin/index.txt | 114 | ||||
| -rw-r--r-- | docs/ref/databases.txt | 35 | ||||
| -rw-r--r-- | docs/ref/models/querysets.txt | 2 |
3 files changed, 140 insertions, 11 deletions
diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt index bad7dec390..64d9c52492 100644 --- a/docs/ref/contrib/admin/index.txt +++ b/docs/ref/contrib/admin/index.txt @@ -667,6 +667,43 @@ Controls where on the page the actions bar appears. By default, the admin changelist displays actions at the top of the page (``actions_on_top = True; actions_on_bottom = False``). +.. attribute:: ModelAdmin.change_list_template + +Path to a custom template that will be used by the model objects "change list" +view. Templates can override or extend base admin templates as described in +`Overriding Admin Templates`_. + +If you don't specify this attribute, a default template shipped with Django +that provides the standard appearance is used. + +.. attribute:: ModelAdmin.change_form_template + +Path to a custom template that will be used by both the model object creation +and change views. Templates can override or extend base admin templates as +described in `Overriding Admin Templates`_. + +If you don't specify this attribute, a default template shipped with Django +that provides the standard appearance is used. + +.. attribute:: ModelAdmin.object_history_template + +Path to a custom template that will be used by the model object change history +display view. Templates can override or extend base admin templates as +described in `Overriding Admin Templates`_. + +If you don't specify this attribute, a default template shipped with Django +that provides the standard appearance is used. + +.. attribute:: ModelAdmin.delete_confirmation_template + +Path to a custom template that will be used by the view responsible of showing +the confirmation page when the user decides to delete one or more model +objects. Templates can override or extend base admin templates as described in +`Overriding Admin Templates`_. + +If you don't specify this attribute, a default template shipped with Django +that provides the standard appearance is used. + ``ModelAdmin`` methods ---------------------- @@ -762,6 +799,56 @@ return a subset of objects for this foreign key field based on the user:: This uses the ``HttpRequest`` instance to filter the ``Car`` foreign key field to only the cars owned by the ``User`` instance. +Other methods +~~~~~~~~~~~~~ + +.. method:: ModelAdmin.add_view(self, request, form_url='', extra_context=None) + +Django view for the model instance addition page. See note below. + +.. method:: ModelAdmin.change_view(self, request, object_id, extra_context=None) + +Django view for the model instance edition page. See note below. + +.. method:: ModelAdmin.changelist_view(self, request, extra_context=None) + +Django view for the model instances change list/actions page. See note below. + +.. method:: ModelAdmin.delete_view(self, request, object_id, extra_context=None) + +Django view for the model instance(s) deletion confirmation page. See note below. + +.. method:: ModelAdmin.history_view(self, request, object_id, extra_context=None) + +Django view for the page that shows the modification history for a given model +instance. + +Unlike the hook-type ``ModelAdmin`` methods detailed in the previous section, +these five methods are in reality designed to be invoked as Django views from +the admin application URL dispatching handler to render the pages that deal +with model instances CRUD operations. As a result, completely overriding these +methods will significantly change the behavior of the admin application. + +One comon reason for overriding these methods is to augment the context data +that is provided to the template that renders the view. In the following +example, the change view is overridden so that the rendered template is +provided some extra mapping data that would not otherwise be available:: + + class MyModelAdmin(admin.ModelAdmin): + + # A template for a very customized change view: + change_form_template = 'admin/myapp/extras/openstreetmap_change_form.html' + + def get_osm_info(self): + # ... + + def change_view(self, request, object_id, extra_context=None): + my_context = { + 'osm_data': self.get_osm_info(), + } + return super(MyModelAdmin, self).change_view(request, object_id, + extra_context=my_context)) + ``ModelAdmin`` media definitions -------------------------------- @@ -783,7 +870,7 @@ Adding custom validation to the admin ------------------------------------- Adding custom validation of data in the admin is quite easy. The automatic admin -interfaces reuses :mod:`django.forms`, and the ``ModelAdmin`` class gives you +interface reuses :mod:`django.forms`, and the ``ModelAdmin`` class gives you the ability define your own form:: class ArticleAdmin(admin.ModelAdmin): @@ -803,7 +890,9 @@ any field:: It is important you use a ``ModelForm`` here otherwise things can break. See the :ref:`forms <ref-forms-index>` documentation on :ref:`custom validation -<ref-forms-validation>` for more information. +<ref-forms-validation>` and, more specifically, the +:ref:`model form validation notes <overriding-modelform-clean-method>` for more +information. .. _admin-inlines: @@ -1106,7 +1195,7 @@ directory, our link would appear on every model's change form. Templates which may be overridden per app or model -------------------------------------------------- -Not every template in ``contrib\admin\templates\admin`` may be overridden per +Not every template in ``contrib/admin/templates/admin`` may be overridden per app or per model. The following can: * ``app_index.html`` @@ -1131,8 +1220,8 @@ Root and login templates ------------------------ If you wish to change the index or login templates, you are better off creating -your own ``AdminSite`` instance (see below), and changing the ``index_template`` -or ``login_template`` properties. +your own ``AdminSite`` instance (see below), and changing the :attr:`AdminSite.index_template` +or :attr:`AdminSite.login_template` properties. ``AdminSite`` objects ===================== @@ -1151,6 +1240,21 @@ or add anything you like. Then, simply create an instance of your Python class), and register your models and ``ModelAdmin`` subclasses with it instead of using the default. +``AdminSite`` attributes +------------------------ + +.. attribute:: AdminSite.index_template + +Path to a custom template that will be used by the admin site main index view. +Templates can override or extend base admin templates as described in +`Overriding Admin Templates`_. + +.. attribute:: AdminSite.login_template + +Path to a custom template that will be used by the admin site login view. +Templates can override or extend base admin templates as described in +`Overriding Admin Templates`_. + Hooking ``AdminSite`` instances into your URLconf ------------------------------------------------- diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt index 76a4159235..9a35b6cb8f 100644 --- a/docs/ref/databases.txt +++ b/docs/ref/databases.txt @@ -251,7 +251,7 @@ Here's a sample configuration which uses a MySQL option file:: DATABASE_OPTIONS = { 'read_default_file': '/path/to/my.cnf', } - + # my.cnf [client] database = DATABASE_NAME @@ -445,10 +445,10 @@ If you're getting this error, you can solve it by: * Switching to another database backend. At a certain point SQLite becomes too "lite" for real-world applications, and these sorts of concurrency errors indicate you've reached that point. - - * Rewriting your code to reduce concurrency and ensure that database + + * Rewriting your code to reduce concurrency and ensure that database transactions are short-lived. - + * Increase the default timeout value by setting the ``timeout`` database option option:: @@ -457,7 +457,7 @@ If you're getting this error, you can solve it by: "timeout": 20, # ... } - + This will simply make SQLite wait a bit longer before throwing "database is locked" errors; it won't really do anything to solve them. @@ -601,3 +601,28 @@ some limitations on the usage of such LOB columns in general: Oracle. A workaround to this is to keep ``TextField`` columns out of any models that you foresee performing ``distinct()`` queries on, and to include the ``TextField`` in a related model instead. + +.. _third-party-notes: + +Using a 3rd-party database backend +================================== + +In addition to the officially supported databases, there are backends provided +by 3rd parties that allow you to use other databases with Django: + +* `Sybase SQL Anywhere`_ +* `IBM DB2`_ +* `Microsoft SQL Server 2005`_ +* Firebird_ +* ODBC_ + +The Django versions and ORM features supported by these unofficial backends +vary considerably. Queries regarding the specific capabilities of these +unofficial backends, along with any support queries, should be directed to +the support channels provided by each 3rd party project. + +.. _Sybase SQL Anywhere: http://code.google.com/p/sqlany-django/ +.. _IBM DB2: http://code.google.com/p/ibm-db/ +.. _Microsoft SQL Server 2005: http://code.google.com/p/django-mssql/ +.. _Firebird: http://code.google.com/p/django-firebird/ +.. _ODBC: http://code.google.com/p/django-pyodbc/ diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt index eb8fbfd833..348486b341 100644 --- a/docs/ref/models/querysets.txt +++ b/docs/ref/models/querysets.txt @@ -35,7 +35,7 @@ You can evaluate a ``QuerySet`` in the following ways: * **Slicing.** As explained in :ref:`limiting-querysets`, a ``QuerySet`` can be sliced, using Python's array-slicing syntax. Usually slicing a - ``QuerySet`` returns another (unevaluated ) ``QuerySet``, but Django will + ``QuerySet`` returns another (unevaluated) ``QuerySet``, but Django will execute the database query if you use the "step" parameter of slice syntax. |