Changes between Version 59 and Version 60 of NewformsAdminBranch

Timestamp:

Jul 9, 2008, 12:47:33 PM (16 years ago)

Author:

Brian Rosner

Comment:

edited more of the page to reflect current status removing bits no longer relevant in the common case

NewformsAdminBranch

@@ -62 +62 @@
 #!python
 
-# models.py
-
-from django.contrib import admin
+# project-level admin.py
+
+from django.contrib import admin
+from myproject.myapp.models import Book, Author
+from myproject.anotherapp.models import Musician, Instrument
 
 site1 = admin.AdminSite()
@@ -77 +79 @@
 
 from django.conf.urls.defaults import *
-from myproject.myapp.models import site1, site2
+from myproject.admin import site1, site2
 
 urlpatterns = patterns('',
@@ -106 +108 @@
     author = models.ForeignKey(Author)
 
+# a sample admin.py file (in same app)
+from django.contrib import admin
+from myproject.myapp.models import Author, Book
+
 class BookAdmin(admin.ModelAdmin):
     list_display = ('title', 'author')
     ordering = ('title',)
 
-# Make sure the following are executed exactly once (i.e., watch your imports), or you'll see AlreadyRegistered exceptions.
 admin.site.register(Author)
 admin.site.register(Book, BookAdmin)
@@ -116 +121 @@
 
 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 {{{BookAdmin}}} class and pass that class as a second argument to {{{admin.site.register()}}}.
-
-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 this.[[BR]]
-
-'''A proposed convention''': Specifying all admin options in a file called {{{admins.py}}}, and import it in the {{{__init__.py}}} file of your application module to do the registering during the initialization. In this case the above example would look like this:
-{{{
-#!python
-# a sample models.py file
-from django.db import models
-
-class Author(models.Model):
-    first_name = models.CharField(max_length=30)
-    last_name = models.CharField(max_length=30)
-
-    def __unicode__(self):
-        return u'%s %s' % (self.first_name, self.last_name)
-
-class Book(models.Model):
-    title = models.CharField(max_length=100)
-    author = models.ForeignKey(Author)
-
-# a sample admins.py file
-from django.contrib import admin
-
-class BookAdmin(admin.ModelAdmin):
-    list_display = ('title', 'author')
-    ordering = ('title',)
-
-# a sample __init__.py file
-from django.contrib import admin
-from project.app.models import Author, Book
-from project.app.admins import BookAdmin
-
-# Make sure the following are executed exactly once (i.e., watch your imports), or you'll see AlreadyRegistered exceptions.
-# Meaning if you use project.app, be sure to use project.app everywhere, including in url configuration (i.e. use 'project.app.views')
-admin.site.register(Author)
-admin.site.register(Book, BookAdmin)
-}}}
 
 You'll notice the {{{BookAdmin}}} 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: