innov
/
django1
1
0
Fork 0
Code Issues Pull Requests 1 Projects Releases Wiki Activity

Fixed #10030 -- Corrected a typo in a reference to the login_required decorator. Thanks to mk for the report. 

git-svn-id: http://code.djangoproject.com/svn/django/trunk@9860 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Russell Keith-Magee 2009-02-22 06:08:13 +00:00
parent b1d487e0f8
commit f1e8d24e0c
1 changed files with 47 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

94
docs/ref/contrib/admin.txt
View File

@ -64,9 +64,9 @@ Let's take a look at a very simple example of the ``ModelAdmin``::
from django.contrib import admin
from myproject.myapp.models import Author
admin.site.register(Author)
``ModelAdmin`` Options
----------------------
@ -138,13 +138,13 @@ The ``field_options`` dictionary can have the following keys:
* ``fields``
A tuple of field names to display in this fieldset. This key is
required.
Example::
{
'fields': ('first_name', 'last_name', 'address', 'city', 'state'),
}
To display multiple fields on the same line, wrap those fields in
their own tuple. In this example, the ``first_name`` and ``last_name``
fields will display on the same line::
@ -155,9 +155,9 @@ The ``field_options`` dictionary can have the following keys:
* ``classes``
A list containing extra CSS classes to apply to the fieldset.
Example::
{
'classes': ['wide', 'extrapretty'],
}
@ -213,10 +213,10 @@ For example, let's consider the following model::
If you want a form for the ``Author`` model that includes only the ``name``
and ``title`` fields, you would specify ``fields`` or ``exclude`` like this::
class AuthorAdmin(admin.ModelAdmin):
fields = ('name', 'title')
class AuthorAdmin(admin.ModelAdmin):
exclude = ('birth_date',)
@ -254,30 +254,30 @@ that displays the ``__unicode__()`` representation of each object.
You have four possible values that can be used in ``list_display``:
* A field of the model. For example::
class PersonAdmin(admin.ModelAdmin):
list_display = ('first_name', 'last_name')
* A callable that accepts one parameter for the model instance. For
example::
def upper_case_name(obj):
return ("%s %s" % (obj.first_name, obj.last_name)).upper()
upper_case_name.short_description = 'Name'
class PersonAdmin(admin.ModelAdmin):
list_display = (upper_case_name,)
* A string representing an attribute on the ``ModelAdmin``. This behaves
same as the callable. For example::
class PersonAdmin(admin.ModelAdmin):
list_display = ('upper_case_name',)
def upper_case_name(self, obj):
return ("%s %s" % (obj.first_name, obj.last_name)).upper()
upper_case_name.short_description = 'Name'
* A string representing an attribute on the model. This behaves almost
the same as the callable, but ``self`` in this context is the model
instance. Here's a full model example::
@ -311,7 +311,7 @@ A few special cases to note about ``list_display``:
callable, Django will HTML-escape the output by default. If you'd rather
not escape the output of the method, give the method an ``allow_tags``
attribute whose value is ``True``.
Here's a full example model::
class Person(models.Model):
@ -613,16 +613,16 @@ do that::
from django.db import models
from django.contrib import admin
# Import our custom widget and our model from where they're defined
from myapp.widgets import RichTextEditorWidget
from myapp.models import MyModel
class MyModelAdmin(admin.ModelAdmin):
formfield_overrides = {
models.TextField: {'widget': RichTextEditorWidget},
}
Note that the key in the dictionary is the actual field class, *not* a string.
The value is another dictionary; these arguments will be passed to
:meth:`~django.forms.Field.__init__`. See :ref:`ref-forms-api` for details.
@ -676,18 +676,18 @@ model instance::
``get_urls(self)``
~~~~~~~~~~~~~~~~~~~
The ``get_urls`` method on a ``ModelAdmin`` returns the URLs to be used for
that ModelAdmin in the same way as a URLconf. Therefore you can extend them as
The ``get_urls`` method on a ``ModelAdmin`` returns the URLs to be used for
that ModelAdmin in the same way as a URLconf. Therefore you can extend them as
documented in :ref:`topics-http-urls`::
class MyModelAdmin(admin.ModelAdmin):
def get_urls(self):
urls = super(MyModelAdmin, self).get_urls()
my_urls = patterns('',
(r'^my_view/$', self.my_view)
)
)
return my_urls + urls
.. note::
Notice that the custom patterns are included *before* the regular admin
@ -707,13 +707,13 @@ so::
urls = super(MyModelAdmin, self).get_urls()
my_urls = patterns('',
(r'^my_view/$', self.admin_site.admin_view(self.my_view))
)
)
return my_urls + urls
Notice the wrapped view in the fifth line above::
(r'^my_view/$', self.admin_site.admin_view(self.my_view))
This wrapping will protect ``self.my_view`` from unauthorized access.
``formfield_for_foreignkey(self, db_field, request, **kwargs)``
@ -763,11 +763,11 @@ the ability define your own form::
``MyArticleAdminForm`` can be defined anywhere as long as you import where
needed. Now within your form you can add your own custom validation for
any field::
class MyArticleAdminForm(forms.ModelForm):
class Meta:
model = Article
def clean_name(self):
# do something that validates your data
return self.cleaned_data["name"]
@ -906,7 +906,7 @@ Working with Many-to-Many Intermediary Models
By default, admin widgets for many-to-many relations will be displayed inline
on whichever model contains the actual reference to the ``ManyToManyField``.
However, when you specify an intermediary model using the ``through``
argument to a ``ManyToManyField``, the admin will not display a widget by
argument to a ``ManyToManyField``, the admin will not display a widget by
default. This is because each instance of that intermediary model requires
more information than could be displayed in a single widget, and the layout
required for multiple widgets will vary depending on the intermediate model.
@ -917,7 +917,7 @@ models::
class Person(models.Model):
name = models.CharField(max_length=128)
class Group(models.Model):
name = models.CharField(max_length=128)
members = models.ManyToManyField(Person, through='Membership')
@ -948,7 +948,7 @@ Now create admin views for the ``Person`` and ``Group`` models::
inlines = (MembershipInline,)
Finally, register your ``Person`` and ``Group`` models with the admin site::
admin.site.register(Person, PersonAdmin)
admin.site.register(Group, GroupAdmin)
@ -966,7 +966,7 @@ you have the following models::
content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
content_object = generic.GenericForeignKey("content_type", "object_id")
class Product(models.Model):
name = models.CharField(max_length=100)
@ -977,17 +977,17 @@ example app::
from django.contrib import admin
from django.contrib.contenttypes import generic
from myproject.myapp.models import Image, Product
class ImageInline(generic.GenericTabularInline):
model = Image
class ProductAdmin(admin.ModelAdmin):
inlines = [
ImageInline,
]
admin.site.register(Product, ProductAdmin)
``django.contrib.contenttypes.generic`` provides both a ``GenericTabularInline``
@ -1174,8 +1174,8 @@ respectively::
Adding views to admin sites
---------------------------
It possible to add additional views to the admin site in the same way one can
add them to ``ModelAdmins``. This by using the ``get_urls()`` method on an
It possible to add additional views to the admin site in the same way one can
add them to ``ModelAdmins``. This by using the ``get_urls()`` method on an
AdminSite in the same way as `described above`__
__ `get_urls(self)`_
@ -1183,13 +1183,13 @@ __ `get_urls(self)`_
Protecting Custom ``AdminSite`` and ``ModelAdmin``
--------------------------------------------------
By default all the views in the Django admin are protected so that only staff
members can access them. If you add your own views to either a ``ModelAdmin``
or ``AdminSite`` you should ensure that where necessary they are protected in
the same manner. To do this use the ``admin_perm_test`` decorator provided in
``django.contrib.admin.utils.admin_perm_test``. It can be used in the same way
as the ``login_requied`` decorator.
By default all the views in the Django admin are protected so that only staff
members can access them. If you add your own views to either a ``ModelAdmin``
or ``AdminSite`` you should ensure that where necessary they are protected in
the same manner. To do this use the ``admin_perm_test`` decorator provided in
``django.contrib.admin.utils.admin_perm_test``. It can be used in the same way
as the ``login_required`` decorator.
.. note::
The ``admin_perm_test`` decorator can only be used on methods which are on
The ``admin_perm_test`` decorator can only be used on methods which are on
``ModelAdmins`` or ``AdminSites``, you cannot use it on arbitrary functions.