Changes between Version 26 and Version 27 of NewformsAdminBranch


Ignore:
Timestamp:
09/16/07 01: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       )
Back to Top