Changes between Version 15 and Version 16 of NewformsAdminBranch
- Timestamp:
- Apr 7, 2007, 12:12:18 AM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
NewformsAdminBranch
v15 v16 1 1 = The newforms-admin branch = 2 2 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.3 This 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. 4 4 5 5 == How to get the branch == … … 13 13 == Goals == 14 14 15 In no particular order, here are the goals of this branch. This list may expand as we get more ideas. 15 The main goals of this branch are: 16 16 17 17 * Change the admin site to use newforms instead of automatic manipulators. … … 47 47 }}} 48 48 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. 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. 50 51 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. 50 52 51 53 In this example, we create two {{{AdminSite}}} instances, registering different models with both. Assume {{{Book}}}, {{{Author}}}, {{{Musician}}} and {{{Instrument}}} are Django model classes (not instances). … … 75 77 With 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. 76 78 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:79 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: 78 80 79 81 {{{ … … 105 107 In 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()}}}. 106 108 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 111 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: 108 112 109 113 {{{ … … 119 123 """ 120 124 if request.user.username == 'john': 121 return obj.author. id = 3 # Roald Dahl books125 return obj.author.last_name == 'Dahl' 122 126 return super(BookOptions, self).has_change_permission(request, obj) 123 127 }}}