Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

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
  • Loading branch information...
commit f1e8d24e0c3d6aafaf2550eb19e58158a7339fd7 1 parent b1d487e
Russell Keith-Magee authored February 22, 2009

Showing 1 changed file with 47 additions and 47 deletions. Show diff stats Hide diff stats

  1. 94  docs/ref/contrib/admin.txt
94  docs/ref/contrib/admin.txt
@@ -64,9 +64,9 @@ Let's take a look at a very simple example of the ``ModelAdmin``::
64 64
 
65 65
         from django.contrib import admin
66 66
         from myproject.myapp.models import Author
67  
-    
  67
+
68 68
         admin.site.register(Author)
69  
-    
  69
+
70 70
 ``ModelAdmin`` Options
71 71
 ----------------------
72 72
 
@@ -138,13 +138,13 @@ The ``field_options`` dictionary can have the following keys:
138 138
     * ``fields``
139 139
         A tuple of field names to display in this fieldset. This key is
140 140
         required.
141  
-        
  141
+
142 142
         Example::
143  
-        
  143
+
144 144
             {
145 145
             'fields': ('first_name', 'last_name', 'address', 'city', 'state'),
146 146
             }
147  
-            
  147
+
148 148
         To display multiple fields on the same line, wrap those fields in
149 149
         their own tuple. In this example, the ``first_name`` and ``last_name``
150 150
         fields will display on the same line::
@@ -155,9 +155,9 @@ The ``field_options`` dictionary can have the following keys:
155 155
 
156 156
     * ``classes``
157 157
         A list containing extra CSS classes to apply to the fieldset.
158  
-        
  158
+
159 159
         Example::
160  
-        
  160
+
161 161
             {
162 162
             'classes': ['wide', 'extrapretty'],
163 163
             }
@@ -213,10 +213,10 @@ For example, let's consider the following model::
213 213
 
214 214
 If you want a form for the ``Author`` model that includes only the ``name``
215 215
 and ``title`` fields, you would specify ``fields`` or ``exclude`` like this::
216  
-    
  216
+
217 217
     class AuthorAdmin(admin.ModelAdmin):
218 218
         fields = ('name', 'title')
219  
-    
  219
+
220 220
     class AuthorAdmin(admin.ModelAdmin):
221 221
         exclude = ('birth_date',)
222 222
 
@@ -254,30 +254,30 @@ that displays the ``__unicode__()`` representation of each object.
254 254
 You have four possible values that can be used in ``list_display``:
255 255
 
256 256
     * A field of the model. For example::
257  
-    
  257
+
258 258
           class PersonAdmin(admin.ModelAdmin):
259 259
               list_display = ('first_name', 'last_name')
260  
-    
  260
+
261 261
     * A callable that accepts one parameter for the model instance. For
262 262
       example::
263  
-    
  263
+
264 264
           def upper_case_name(obj):
265 265
               return ("%s %s" % (obj.first_name, obj.last_name)).upper()
266 266
           upper_case_name.short_description = 'Name'
267  
-        
  267
+
268 268
           class PersonAdmin(admin.ModelAdmin):
269 269
               list_display = (upper_case_name,)
270  
-    
  270
+
271 271
     * A string representing an attribute on the ``ModelAdmin``. This behaves
272 272
       same as the callable. For example::
273  
-      
  273
+
274 274
           class PersonAdmin(admin.ModelAdmin):
275 275
               list_display = ('upper_case_name',)
276  
-              
  276
+
277 277
               def upper_case_name(self, obj):
278 278
                 return ("%s %s" % (obj.first_name, obj.last_name)).upper()
279 279
               upper_case_name.short_description = 'Name'
280  
-    
  280
+
281 281
     * A string representing an attribute on the model. This behaves almost
282 282
       the same as the callable, but ``self`` in this context is the model
283 283
       instance. Here's a full model example::
@@ -311,7 +311,7 @@ A few special cases to note about ``list_display``:
311 311
       callable, Django will HTML-escape the output by default. If you'd rather
312 312
       not escape the output of the method, give the method an ``allow_tags``
313 313
       attribute whose value is ``True``.
314  
-      
  314
+
315 315
       Here's a full example model::
316 316
 
317 317
           class Person(models.Model):
@@ -613,16 +613,16 @@ do that::
613 613
 
614 614
     from django.db import models
615 615
     from django.contrib import admin
616  
-    
  616
+
617 617
     # Import our custom widget and our model from where they're defined
618 618
     from myapp.widgets import RichTextEditorWidget
619 619
     from myapp.models import MyModel
620  
-    
  620
+
621 621
     class MyModelAdmin(admin.ModelAdmin):
622 622
         formfield_overrides = {
623 623
             models.TextField: {'widget': RichTextEditorWidget},
624 624
         }
625  
-        
  625
+
626 626
 Note that the key in the dictionary is the actual field class, *not* a string.
627 627
 The value is another dictionary; these arguments will be passed to
628 628
 :meth:`~django.forms.Field.__init__`. See :ref:`ref-forms-api` for details.
@@ -676,18 +676,18 @@ model instance::
676 676
 ``get_urls(self)``
677 677
 ~~~~~~~~~~~~~~~~~~~
678 678
 
679  
-The ``get_urls`` method on a ``ModelAdmin`` returns the URLs to be used for 
680  
-that ModelAdmin in the same way as a URLconf.  Therefore you can extend them as 
  679
+The ``get_urls`` method on a ``ModelAdmin`` returns the URLs to be used for
  680
+that ModelAdmin in the same way as a URLconf.  Therefore you can extend them as
681 681
 documented in :ref:`topics-http-urls`::
682  
-    
  682
+
683 683
     class MyModelAdmin(admin.ModelAdmin):
684 684
         def get_urls(self):
685 685
             urls = super(MyModelAdmin, self).get_urls()
686 686
             my_urls = patterns('',
687 687
                 (r'^my_view/$', self.my_view)
688  
-            ) 
  688
+            )
689 689
             return my_urls + urls
690  
-            
  690
+
691 691
 .. note::
692 692
 
693 693
     Notice that the custom patterns are included *before* the regular admin
@@ -707,13 +707,13 @@ so::
707 707
             urls = super(MyModelAdmin, self).get_urls()
708 708
             my_urls = patterns('',
709 709
                 (r'^my_view/$', self.admin_site.admin_view(self.my_view))
710  
-            ) 
  710
+            )
711 711
             return my_urls + urls
712 712
 
713 713
 Notice the wrapped view in the fifth line above::
714 714
 
715 715
     (r'^my_view/$', self.admin_site.admin_view(self.my_view))
716  
-    
  716
+
717 717
 This wrapping will protect ``self.my_view`` from unauthorized access.
718 718
 
719 719
 ``formfield_for_foreignkey(self, db_field, request, **kwargs)``
@@ -763,11 +763,11 @@ the ability define your own form::
763 763
 ``MyArticleAdminForm`` can be defined anywhere as long as you import where
764 764
 needed. Now within your form you can add your own custom validation for
765 765
 any field::
766  
-    
  766
+
767 767
     class MyArticleAdminForm(forms.ModelForm):
768 768
         class Meta:
769 769
             model = Article
770  
-        
  770
+
771 771
         def clean_name(self):
772 772
             # do something that validates your data
773 773
             return self.cleaned_data["name"]
@@ -906,7 +906,7 @@ Working with Many-to-Many Intermediary Models
906 906
 By default, admin widgets for many-to-many relations will be displayed inline
907 907
 on whichever model contains the actual reference to the ``ManyToManyField``.
908 908
 However, when you specify an intermediary model using the ``through``
909  
-argument to a ``ManyToManyField``, the admin will not display a widget by 
  909
+argument to a ``ManyToManyField``, the admin will not display a widget by
910 910
 default. This is because each instance of that intermediary model requires
911 911
 more information than could be displayed in a single widget, and the layout
912 912
 required for multiple widgets will vary depending on the intermediate model.
@@ -917,7 +917,7 @@ models::
917 917
 
918 918
     class Person(models.Model):
919 919
         name = models.CharField(max_length=128)
920  
-    
  920
+
921 921
     class Group(models.Model):
922 922
         name = models.CharField(max_length=128)
923 923
         members = models.ManyToManyField(Person, through='Membership')
@@ -948,7 +948,7 @@ Now create admin views for the ``Person`` and ``Group`` models::
948 948
         inlines = (MembershipInline,)
949 949
 
950 950
 Finally, register your ``Person`` and ``Group`` models with the admin site::
951  
-    
  951
+
952 952
     admin.site.register(Person, PersonAdmin)
953 953
     admin.site.register(Group, GroupAdmin)
954 954
 
@@ -966,7 +966,7 @@ you have the following models::
966 966
         content_type = models.ForeignKey(ContentType)
967 967
         object_id = models.PositiveIntegerField()
968 968
         content_object = generic.GenericForeignKey("content_type", "object_id")
969  
-    
  969
+
970 970
     class Product(models.Model):
971 971
         name = models.CharField(max_length=100)
972 972
 
@@ -977,17 +977,17 @@ example app::
977 977
 
978 978
     from django.contrib import admin
979 979
     from django.contrib.contenttypes import generic
980  
-    
  980
+
981 981
     from myproject.myapp.models import Image, Product
982  
-    
  982
+
983 983
     class ImageInline(generic.GenericTabularInline):
984 984
         model = Image
985  
-    
  985
+
986 986
     class ProductAdmin(admin.ModelAdmin):
987 987
         inlines = [
988 988
             ImageInline,
989 989
         ]
990  
-    
  990
+
991 991
     admin.site.register(Product, ProductAdmin)
992 992
 
993 993
 ``django.contrib.contenttypes.generic`` provides both a ``GenericTabularInline``
@@ -1174,8 +1174,8 @@ respectively::
1174 1174
 Adding views to admin sites
1175 1175
 ---------------------------
1176 1176
 
1177  
-It possible to add additional views to the admin site in the same way one can 
1178  
-add them to ``ModelAdmins``.  This by using the ``get_urls()`` method on an 
  1177
+It possible to add additional views to the admin site in the same way one can
  1178
+add them to ``ModelAdmins``.  This by using the ``get_urls()`` method on an
1179 1179
 AdminSite in the same way as `described above`__
1180 1180
 
1181 1181
 __ `get_urls(self)`_
@@ -1183,13 +1183,13 @@ __ `get_urls(self)`_
1183 1183
 Protecting Custom ``AdminSite`` and ``ModelAdmin``
1184 1184
 --------------------------------------------------
1185 1185
 
1186  
-By default all the views in the Django admin are protected so that only staff 
1187  
-members can access them.  If you add your own views to either a ``ModelAdmin`` 
1188  
-or ``AdminSite`` you should ensure that where necessary they are protected in 
1189  
-the same manner.  To do this use the ``admin_perm_test`` decorator provided in 
1190  
-``django.contrib.admin.utils.admin_perm_test``.  It can be used in the same way 
1191  
-as the ``login_requied`` decorator.
  1186
+By default all the views in the Django admin are protected so that only staff
  1187
+members can access them.  If you add your own views to either a ``ModelAdmin``
  1188
+or ``AdminSite`` you should ensure that where necessary they are protected in
  1189
+the same manner.  To do this use the ``admin_perm_test`` decorator provided in
  1190
+``django.contrib.admin.utils.admin_perm_test``.  It can be used in the same way
  1191
+as the ``login_required`` decorator.
1192 1192
 
1193 1193
 .. note::
1194  
-    The ``admin_perm_test`` decorator can only be used on methods which are on 
  1194
+    The ``admin_perm_test`` decorator can only be used on methods which are on
1195 1195
     ``ModelAdmins`` or ``AdminSites``, you cannot use it on arbitrary functions.

0 notes on commit f1e8d24

Please sign in to comment.
Something went wrong with that request. Please try again.