Code

Changes between Version 15 and Version 16 of NewformsAdminBranch


Ignore:
Timestamp:
04/06/07 22:12:18 (7 years ago)
Author:
adrian
Comment:

Some more edits

Legend:

Unmodified
Added
Removed
Modified
  • NewformsAdminBranch

    v15 v16  
    11= The newforms-admin branch = 
    22 
    3 This branch aims to integrate Django's admin site with the [http://www.djangoproject.com/documentation/newforms/ newforms library]. Along the way, we'll take the opportunity to add extra customization hooks to the admin site, in preparation for a complete admin-site refactoring in the future. 
     3This branch aims to integrate Django's admin site with the [http://www.djangoproject.com/documentation/newforms/ newforms library]. Along the way, we're taking the opportunity to add extra customization hooks to the admin site. 
    44 
    55== How to get the branch == 
     
    1313== Goals == 
    1414 
    15 In no particular order, here are the goals of this branch. This list may expand as we get more ideas. 
     15The main goals of this branch are: 
    1616 
    1717  * Change the admin site to use newforms instead of automatic manipulators. 
     
    4747}}} 
    4848 
    49 Note that, in this above URLconf example, we're dealing with the object {{{django.contrib.admin.site}}}. This is an instance of {{{django.contrib.admin.AdminSite}}}, which is a class that lets you specify admin-site functionality. The object {{{django.contrib.admin.site}}} is a default {{{AdminSite}}} instance that is created for you automatically, but you can also create other instances as you see fit. Previously, there was one "global" version of the admin site, which used all models that contained a {{{class Admin}}}. This new scheme allows for much more fine-grained control over your admin sites, allowing you to have multiple admin sites in the same Django instance. 
     49Note that, in this above URLconf example, we're dealing with the object {{{django.contrib.admin.site}}}. This is an instance of {{{django.contrib.admin.AdminSite}}}, which is a class that lets you specify admin-site functionality. The object {{{django.contrib.admin.site}}} is a default {{{AdminSite}}} instance that is created for you automatically, but you can also create other instances as you see fit. 
     50 
     51Previously, there was one "global" version of the admin site, which used all models that contained a {{{class Admin}}}. This new scheme allows for much more fine-grained control over your admin sites, allowing you to have multiple admin sites in the same Django instance. 
    5052 
    5153In this example, we create two {{{AdminSite}}} instances, registering different models with both. Assume {{{Book}}}, {{{Author}}}, {{{Musician}}} and {{{Instrument}}} are Django model classes (not instances). 
     
    7577With this example, if you go to {{{/book_admin/}}}, you'll get a Django admin site for the {{{Book}}} and {{{Author}}} models. If you go to {{{/music_admin/}}}, you'll get a Django admin site for the {{{Musician}}} and {{{Instrument}}} models. 
    7678 
    77 Admin options -- the inner {{{class Admin}}} -- have changed, too. Models no longer use an inner class to declare their admin site options. In fact, *all admin functionality has been decoupled from the model syntax*! How, then, do we declare admin options? Like this: 
     79Admin options -- the inner {{{class Admin}}} -- have changed, too. Models no longer use an inner class to declare their admin site options. In fact, **all admin functionality has been decoupled from the model syntax**! How, then, do we declare admin options? Like this: 
    7880 
    7981{{{ 
     
    105107In 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()}}}. 
    106108 
    107 You'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: 
     109(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}}}.) 
     110 
     111You'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: 
    108112 
    109113{{{ 
     
    119123        """ 
    120124        if request.user.username == 'john': 
    121             return obj.author.id = 3 # Roald Dahl books 
     125            return obj.author.last_name == 'Dahl' 
    122126        return super(BookOptions, self).has_change_permission(request, obj) 
    123127}}}