Code

Changes between Version 26 and Version 27 of NewformsAdminBranch


Ignore:
Timestamp:
09/15/07 23:50:39 (7 years ago)
Author:
jdetaeye@…
Comment:

added some info an backward incompatible changes

Legend:

Unmodified
Added
Removed
Modified
  • NewformsAdminBranch

    v26 v27  
    108108In this example, we register both {{{Author}}} and {{{Book}}} with the {{{AdminSite}}} instance {{{django.contrib.admin.site}}}. {{{Author}}} doesn't need any custom admin options, so we just call {{{admin.site.register(Author)}}}. {{{Book}}}, on the other hand, has some custom admin options, so we define a {{{BookOptions}}} class and pass that class as a second argument to {{{admin.site.register()}}}. 
    109109 
    110 (Yes, in this example, the admin options still live in the {{{models.py}}} file. But there's nothing that requires them to do so. The only requirement is that the {{{register()}}} calls are executed at some point, and putting them in the {{{models.py}}} is an easy way to ensure that. We'll likely come up with a nice convention for specifying admin options, perhaps in a file called {{{admin.py}}}.) 
     110In this example, the admin options still live in the {{{models.py}}} file. But there's nothing that requires them to do so. The only requirement is that the {{{register()}}} calls are executed at some point, and putting them in the {{{models.py}}} is an easy way to ensure that. We'll likely come up with a nice convention for this.[[BR]] 
     111A proposal convention: Specifying all admin options in a file called {{{admin.py}}}, and import it in the {{{__init.py}}} file of your application module to do the registering during the initialization. 
    111112 
    112113You'll notice the {{{BookOptions}}} class looks a lot like the old-style {{{class Admin}}}. Almost all of the old {{{class Admin}}} options work exactly the same, with one or two exceptions. (For the options that have changed, we've made them '''much''' more powerful.) In addition to the classic options such as {{{list_display}}} and {{{ordering}}}, the {{{ModelAdmin}}} class introduces a wealth of extra hooks you can use to customize the admin site for that particular model. For example: 
     
    195196(r'^admin/doc/', include('django.contrib.admindocs.urls')), 
    196197}}} 
     198 
     199=== Renamed 'fields' to 'fieldsets' === 
     200 
     201'Fields' is used to order and group fields in the change form layout.[[BR]] 
     202It is still available in the new admin, but it accepts only a list of fields. [[BR]] 
     203In case one uses fieldsets to organize the fields, one needs to use 'fieldsets' instead.  
     204 
     205An example: 
     206{{{ 
     207#!python 
     208 
     209# OLD: 
     210class MyModelA(models.Model): 
     211   class Admin: 
     212     fields = ('field1','field2','field3','field4') 
     213 
     214class MyModelB(models.Model): 
     215   class Admin: 
     216     fields = ( 
     217       ('group1', {'fields': ('field1','field2'),), 
     218       ('group2', {'fields': ('field3','field4'),), 
     219       ) 
     220 
     221# NEW: 
     222class MyModelA_Options(admin.ModelAdmin): 
     223    fields = ('field1','field2','field3','field4')  # Renaming is optional  
     224 
     225class MyModelB_Options(admin.ModelAdmin): 
     226     fieldsets = ( 
     227       ('group1', {'fields': ('field1','field2'),), 
     228       ('group2', {'fields': ('field3','field4'),), 
     229       )