Django项目实践4 - Django网站管理(后台管理员)
Posted zsychanpin
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Django项目实践4 - Django网站管理(后台管理员)相关的知识,希望对你有一定的参考价值。
http://blog.csdn.net/pipisorry/article/details/45079751
Introduction
对于某一类站点, 管理界面 是基础设施中很重要的一部分。
这是以网页和有限的可信任管理者为基础的界面,它能够让你加入,编辑和删除站点内容。
常见的样例: 你能够用这个界面公布博客,后台的站点管理者用它来润色读者提交的内容,你的客户用你给他们建立的界面工具更新新闻并公布在站点上。这些都是使用管理界面的样例。
创建管理界面一般是千篇一律的。
你必须认证用户,显示并管理表格,验证输入的有效性诸如此类。Django 的自己主动管理界面: 它读取你模式中的元数据。然后提供给你一个强大可使用的界面,站点管理者能够用它马上工作。
django.contrib包
Django自己主动管理工具是django.contrib的一部分。
django.contrib是一套庞大的功能集。它是Django基本代码的组成部分。Django框架就是由众多包括附加组件(add-on)的基本代码构成的。
管理工具是讲述django.contrib的第一个部分。
从技术层面上讲,它被称作django.contrib.admin。django.contrib中其他可用的特性,如用户鉴别系统(django.contrib.auth)、支持匿名会话(django.contrib.sessioins)以及用户评注系统(django.contrib.comments)。
第十六章具体讨论。Django自带非常多优秀的附加组件,它们都存在于django.contrib包里。
Admin是怎样工作的
当服务启动时,Django从`` url.py`` 引导URLconf。然后运行`` admin.autodiscover()`` 语句。 这个函数遍历INSTALLED_APPS配置。而且寻找相关的admin.py文件。
假设在指定的app文件夹下找到admin.py,它就运行当中的代码。
在`` books`` 应用程序文件夹下的`` admin.py`` 文件里。每次调用`` admin.site.register()`` 都将那个模块注冊到管理工具中。 管理工具仅仅为那些明白注冊了的模块显示一个编辑/改动的界面。
应用程序`` django.contrib.auth`` 包括自身的`` admin.py`` ,所以Users和Groups能在管理工具中自己主动显示。 其他的django.contrib应用程序。从网上下的第三方Django应用程序一样,都会自行加入到管理工具。
综上所述。管理工具事实上就是一个Django应用程序,包括自己的模块、模板、视图和URLpatterns。
你要像加入自己的视图一样,把它加入到URLconf里面。 你能够在Django基本代码中的django/contrib/admin 文件夹下,检查它的模板、视图和URLpatterns,但你不要尝试直接改动当中的不论什么代码,由于里面有非常多地方能够让你自己定义管理工具的工作方式。
激活管理界面
Django管理网站全然是可选择的。由于只某些特殊类型的网站才须要这些功能。
改动settings文件
1. 将‘django.contrib.admin‘增加setting的INSTALLED_APPS配置中 (INSTALLED_APPS中的配置顺序是没有关系的)2. 保证INSTALLED_APPS中包括‘django.contrib.auth‘,‘django.contrib.contenttypes‘和‘django.contrib.sessions‘。Django的管理工具须要这3个包。确保MIDDLEWARE_CLASSES 包括‘django.middleware.common.CommonMiddleware‘ 、‘django.contrib.sessions.middleware.SessionMiddleware‘ 和‘django.contrib.auth.middleware.AuthenticationMiddleware‘ 。
3. 执行 python manage.py syncdb。这一步将生成管理界面使用的额外数据库表。
当你把‘django.contrib.auth‘加进INSTALLED_APPS后,第一次执行syncdb命令时, 系统会请你创建一个超级用户。 假设你不这么作,你须要执行python manage.py createsuperuser来另外创建一个admin的用户帐号,否则你将不能登入admin
Note:仅仅有当INSTALLED_APPS包括‘django.contrib.auth‘时,pythonmanage.py createsuperuser这个命令才可用。
4. 将admin訪问配置在URLconf(urls.py). 默认情况下,命令django-admin.pystartproject生成的文件urls.py是将Django admin的路径凝视掉的。 取消凝视。
# Include these import statements...
from django.contrib import admin
admin.autodiscover()
# And include this URLpattern...
urlpatterns = patterns(‘‘,
# ...
(r‘^admin/‘, include(admin.site.urls)),
# ...
)
使用管理工具
执行Django管理工具
启动开发服务器(python manage.py runserver)。然后在浏览器中訪问:http://127.0.0.1:8000/admin/
登录管理界面
使用你原来设置的超级用户的username和password。
Note:
1. 假设无法登录。请执行`` python manage.py createsuperuser`` 。确保你已经创建了一个超级用户。
2. 假设看到例如以下所看到的的错误页面报告:ImportError at /admin/cannot import name patterns...非常可能使用的 Django 版本号不符合,能够切换到相应的旧版本号教程去或者更新到较新的 Django 版本号。
管理页面
Note:
1. 这个页面列出了管理工具中可编辑的全部数据类型。 它仅有两个默认的管理-编辑模块:用户组(Groups)和用户(Users)。
2. 界面上并没有显示之前创建的数据表。由于我们的这个表没有在admin.py中注冊,也就是admin后台并不知道。后面会讲怎么加入/注冊 -- 将Models加入到Admin管理。
3. 在Django管理页面中,每一种数据类型都有一个* change list* 和* editform* 。前者显示数据库中全部的可用对象;后者可让你加入、更改和删除数据库中的某条记录。
配置Django管理工具语言
假设你的母语不是英语。而你不想用它来配置你的浏览器,你能够做一个高速更改来观察Django管理工具是否被翻译成你想要的语言。
仅需加入`` ‘django.middleware.locale.LocaleMiddleware’`` 到`` MIDDLEWARE_CLASSES`` 设置中,并确保它在’django.contrib.sessions.middleware.SessionMiddleware’* 之后* 。
完毕后。请刷新页面。 假设你设置的语言可用,一系列的链接文字将被显示成这样的语言。这些文字包含页面顶端的Changepassword和Log out,页面中部的Groups和Users。 Django自带了多种语言的翻译。[Django很多其它的国际化特性]
更改列表
点击Uers行中的Change链接。这个页面显示了数据库中全部的用户。
能够将它看作是一个美丽的网页版查询:`` SELECT * FROM auth_user;`` 。你会发现页面中还有过滤器、排序和查询框。 过滤器在右边。排序功能可通过点击列头查看;查询框在页面顶部。它同意你通过username查询。
点击当中一个username。你会看见关于这个用户的编辑窗体。
Note:
1. 这个页面同意你改动用户的属性,如姓名和权限。
(假设要更改用户password,你必须点击password字段下的change the password using this form)
2. 不同类型的字段会用不同的窗体控件显示。
比如,日期/时间型用日历控件,布尔型用复选框。字符型用简单文本框显示。
你会见到一个确认页面。有时候,它会显示有哪些关联的对象将会一并被删除。 (比如,假设你要删除一个出版社。它以下全部的图书也将被删除。
)
4. 你能够通过点击管理主页面中某个对象的Add来加入一条新记录。 一个空白记录的页面将被打开,等待你填充。
5. 你还能看到管理界面也控制着你输入的有效性。 你能够试试不填必需的栏目或者在时间栏里填错误的时间,你会发现当你要保存时会出现错误信息。
6. 当你编辑已有的对像时,你在窗体的右上角能够看到一个历史button。 通过管理界面做的每个改变都留有记录。你能够按历史键来检查这个记录。将Models增加到Admin管理
将自己的模块加入管理工具中。这样我们就行通过这个美丽的界面加入、改动和删除数据库中的对象了。之前我们定义了三个模块:Publisher 、Author 和Book 。
在mysite/books/创建admin.py。输入下面代码,通知管理工具为这些模块逐一提供界面。
from django.contrib import admin from VoteSite.books.models import Publisher, Author, Book # Register your models here. admin.site.register(Publisher) admin.site.register(Author) admin.site.register(Book)完毕后。打开页面`` http://127.0.0.1:8000/admin/`` ,你会看到一个Books区域。当中包括Authors、Books和Publishers。 (你可能须要重新启动runserver)
Note:这里有个奇妙的bug:改动后Djangoserver会报错,但python文件里不报错,把fromVoteSite.books.modelsimportPublisher, Author, Book改动为frombooks.modelsimportPublisher, Author, Book后Django服务器不报错,但python文件里会显示错误,仅仅是这个错误没影响- -,runserver成功!
修正方法:pycharm > settings > languages & framworks > Django > pythonworkspace > Enable Django Support: Django project root:E:\mine\python_workspace\VoteSite settings: VoteSite\settings.py > OK。
这样做是为了告诉python这是一个Django项目。
(跳跳乱说,不能解决)
管理工具处理外键和多对多关系的方法
`` Book`` 模块的样例:
class Book(models.Model): title = models.CharField(max_length=100) authors = models.ManyToManyField(Author) publisher = models.ForeignKey(Publisher) publication_date = models.DateField()
在Add book页面中(`` http://127.0.0.1:8000/admin/books/book/add/`` )。`` 外键`` publisher用一个选择框显示,`` 多对多`` 字段author用一个多选框显示。 点击两个字段后面的绿色加号,能够让你加入相关的记录。
举个样例,假设你点击Publisher后面的加号。你将会得到一个弹出窗体来加入一个publisher。 当你在那个窗体中成功创建了一个publisher后。Add book表单会自己主动把它更新到字段上去.
http://blog.csdn.net/pipisorry/article/details/45079751
自己定义管理工具-自己定义模块
Note:记住这三步来实现模型的变更(否则在日期型和数字型字段设置时保存信息到数据库会成功。但会显示错误)[Django项目实践3 - Django模型]
- 修改你的模型(在models.py中)。
- 执行python manage.py makemigrations命令为这些修改创建迁移文件。
- 执行python manage.py migrate命令将这些修改应用到数据库中。
管理工具有个限制:编辑表单须要你填写每个字段。然而在有些情况下,你想要某些字段是可选的,即同意不填,同意输入空值。
为了指定email字段为可选,你仅仅要编辑Book模块,在email字段上加上blank=True。代码例如以下:
class Author(models.Model):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=40)
email = models.EmailField(blank=True)
这些代码告诉Django,作者的邮箱地址同意输入一个空值。 全部字段都默认blank=False。这使得它们不。
当你加入blank=True以后,刷新页面Add author edit form(http://127.0.0.1:8000/admin/books/author/add/ )。将会发现Email的标签不再是粗体了。
Note:blank=True就是说默认值是‘’。而不是NULL。由于从以下可知,Django生成CREATETABLE语句自己主动为每一个字段显式加上NOT NULL。
设置日期型和数字型字段可选(还有ImageField等)
尽管blank=True相同适用于日期型和数字型字段。可是这里须要具体解说一些背景知识。
SQL有指定空值的独特方式,它把空值叫做NULL。NULL能够表示为未知的、非法的、或其他程序指定的含义。
在SQL中,NULL的值不同于空字符串,就像Python中None不同于空字符串("")一样。这意味着某个字符型字段(如VARCHAR)的值不可能同一时候包括NULL和空字符串。
这会引起不必要的歧义或疑惑。 为什么这条记录有个NULL。而那条记录却有个空字符串? 如何才干得到所有拥有空值的记录,应该按NULL和空字符串查找还是仅按字符串查找?
为了消除歧义,Django生成CREATETABLE语句自己主动为每一个字段显式加上NOT NULL。
生成Author模块的样例:
CREATE TABLE "books_author" (
"id" serial NOT NULL PRIMARY KEY,
"first_name" varchar(30) NOT NULL,
"last_name" varchar(40) NOT NULL,
"email" varchar(75) NOT NULL
);
数据一致性:在管理工具中,假设你留空一个字符型字段,它会为此插入一个空字符串(而不是NULL)。
可是,日期型、时间型和数字型字段不接受空字符串,可能会得到数据库返回的错误。 (PostgreSQL比較严禁,会抛出一个异常;mysql可能会也可能不会接受。
)
在这样的情况下,NULL是唯一指定空值的方法。 因此。假设你想同意一个日期型(DateField、TimeField、DateTimeField)或数字型(IntegerField、DecimalField、FloatField)字段为空,你须要使用null=True 和blank=True。
class Book(models.Model): ‘‘‘ 书籍有书名和出版日期 ‘‘‘ title = models.CharField(max_length=100) authors = models.ManyToManyField(Author) publisher = models.ForeignKey(Publisher) publication_date = models.DateField(blank=True, null=True) def __str__(self): return self.title
由于null=True改变了数据的语义。即改变了CREATETABLE语句,把publication_date字段上的NOTNULL删除了。
要完毕这些修改,我们还须要更新数据库。
出于某种原因,Django不会尝试自己主动更新数据库结构。所以你必须运行ALTERTABLE语句将模块的修改更新至数据库。
能够使用python manage.py dbshell进入数据库服务环境。
ALTER TABLE books_book ALTER COLUMN publication_date DROP NOT NULL;
以上SQL语法是PostgreSQL特有的。
自己定义字段标签在编辑页面中,每一个字段的标签都是从模块的字段名称生成的。 规则非常easy: 用空格替换下划线;首字母大写。比如:Book模块中publication_date的标签是Publication date。
自己定义一个标签。 你仅仅需在模块中指定verbose_name。
将Author.email的标签改为e-mail:
class Author(models.Model):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=40)
email = models.EmailField(blank=True, verbose_name=‘e-mail‘)
改动后重新启动server,你会在author编辑页面中看到这个新标签。
Note:不必把verbose_name的首字母大写,Django会自己主动适时将首字母大写,而且在其他不须要大写的地方使用verbose_name的精确值。
django后台设置可动态增删的add字段
{实现如工作经历随时增删}
class WorkExp(models.Model): work_experience = models.TextField(verbose_name=‘工作经历‘)
class People(models.Model): name = models.CharField(max_length=150, verbose_name=‘姓名‘) #...这样就能够在后台随时点击add。在弹出框中添加工作经历work_experiences = models.ManyToManyField(WorkExp, blank=True, null=True, verbose_name=‘工作经历‘)
Note:在表WorkExp未建立前,后面的+符号是没有的,所以要确保表WorkExp已建立。
自己定义ModelAdmin类-自己定义管理工具
我们做的blank=True、null=True和verbose_name改动事实上是模块级别。而不是管理级别的。 也就是说。这些改动实质上是构成模块的一部分,而且正好被管理工具使用。而不是专门针对管理工具的。
自己定义管理工具选项都在ModelAdmin classes里面,这些类包括了管理工具中针对特别模块的配置。
自己定义显示字段
{自己定义Author模块的列表中的显示字段 - Select *** to change界面}
列表默认地显示查询结果中对象的__unicode__()。
class Author(models.Model): ‘‘‘ 作者有姓。有名及email地址 ‘‘‘ first_name = models.CharField(max_length=30) last_name = models.CharField(max_length=40) email = models.EmailField(blank=True, verbose_name=‘e-mail‘) def __str__(self): return u‘%s %s‘ % (self.first_name, self.last_name)
列表中显示的是每一个作者的姓名。
比方说:在这个列表中能够看到作者的邮箱地址;能依照姓氏或名字来排序。
为Author模块定义一个ModelAdmin类。
这个类是自己定义管理工具的关键,当中最主要的一件事情是同意你指定列表中的字段。
打开admin.py并改动:
from django.contrib import admin from books.models import Publisher, Author, Book class AuthorAdmin(admin.ModelAdmin): list_display = (‘first_name‘, ‘last_name‘, ‘email‘) # Register your models here. admin.site.register(Publisher) # admin.site.register(Author) admin.site.register(Author, AuthorAdmin) admin.site.register(Book)
Note:
1. 新建类AuthorAdmin。从django.contrib.admin.ModelAdmin派生出来的子类。保存着一个类的自己定义配置,以供管理工具使用。
我们仅仅自己定义了一项:list_display, 它是一个字段名称的元组。用于列表显示。
当然。这些字段名称必须是模块中有的。
2. 我们改动了admin.site.register()调用,在Author后面加入了AuthorAdmin: 用AuthorAdmin选项注冊Author模块。admin.site.register()函数接受一个ModelAdmin子类作为第二个參数。
3. the value of list_display must not be a manyToManyField! 如BookAdmin中的list_display不能有authors。
刷新author列表页面
加入一个高速查询栏
{Select *** to change界面}
向AuthorAdmin追加search_fields。如:
class AuthorAdmin(admin.ModelAdmin): list_display = (‘first_name‘, ‘last_name‘, ‘email‘) search_fields = (‘first_name‘, ‘last_name‘)
刷新浏览器。你会在页面顶端看到一个依据姓名查询的查询框。正如用户所希望的那样。它是大写和小写敏感,而且对两个字段检索的查询框。假设查询"bar",那么名字中含有Barney和姓氏中含有Hobarson的作者记录将被检索出来。
加入过滤器
{Select *** to change界面}
from django.contrib import admin from books.models import Publisher, Author, Book class AuthorAdmin(admin.ModelAdmin): list_display = (‘first_name‘, ‘last_name‘, ‘email‘) search_fields = (‘first_name‘, ‘last_name‘) class BookAdmin(admin.ModelAdmin): list_display = (‘title‘, ‘publisher‘, ‘publication_date‘) list_filter = (‘publisher_date‘,) # Register your models here. admin.site.register(Publisher) # admin.site.register(Author) admin.site.register(Author, AuthorAdmin) admin.site.register(Book, BookAdmin)
Note:
1. 因为我们要处理一系列选项。因此我们创建了一个单独的ModelAdmin类:BookAdmin。
2. 首先,我们定义一个list_display,以使得页面好看些。 然后。我们用list_filter这个字段元组创建过滤器,它位于列表页面的右边。
3. Django为日期型字段提供了快捷过滤方式,它包括:今天、过往七天、当月和今年。这些是开发者经经常使用到的。
`` 过滤器`` 相同适用于其他类型的字段
不单是`` 日期型`` (`` 布尔型`` 和`` 外键`` 字段)。
当有两个以上值时,过滤器就会显示。
第二种过滤日期的方式是使用date_hierarchy选项。如:
class BookAdmin(admin.ModelAdmin): list_display = (‘title‘, ‘publisher‘, ‘publication_date‘) list_filter = (‘publication_date‘,) **date_hierarchy = ‘publication_date‘**
改动后页面中的列表顶端会有一个逐层深入的导航条,效果如图 6-11. 它从可用的年份開始,然后逐层细分到月乃至日。
Note:date_hierarchy接受的是* 字符串* ,而不是元组。
由于仅仅能对一个日期型字段进行层次划分。
改变默认的排序方式
按publication date降序排列。 列表页面默认依照模块classMeta中的ordering所指的列排序。但眼下没有指定ordering值。所以当前排序是未定义的。
class BookAdmin(admin.ModelAdmin):
list_display = (‘title‘, ‘publisher‘, ‘publication_date‘)
list_filter = (‘publication_date‘,)
date_hierarchy = ‘publication_date‘
**ordering = (‘-publication_date‘,)**
Note:这个ordering选项基本像模块中classMeta的ordering那样工作。除了它仅仅用列表中的第一个字段名。
假设要实现降序,仅需在传入的列表或元组的字段前加上一个减号(-)。
刷新book列表页面观看实际效果。 注意Publicationdate列头如今有一个小箭头显示排序。
自己定义编辑表单
先自己定义字段顺序。 默认地,表单中的字段顺序是与模块中定义是一致的。通过使用ModelAdmin子类中的fields选项来改变它:
class BookAdmin(admin.ModelAdmin): list_display = (‘title‘, ‘publisher‘, ‘publication_date‘) list_filter = (‘publication_date‘,) date_hierarchy = ‘publication_date‘ ordering = (‘-publication_date‘,) **fields = (‘title‘, ‘authors‘, ‘publisher‘, ‘publication_date‘)**
完毕之后。编辑表单将依照指定的顺序显示各字段。 作者排在书名之后。 字段顺序当然是与数据条文件夹入顺序有关, 每一个表单都不一样。
通过fields这个选项,你能够排除一些不想被其它人编辑的fields 仅仅要不选上不想被编辑的field(s)就可以。 当你的admi用户仅仅是被信任能够更改你的某一部分数据时,或者。你的数据被一些外部的程序自己主动处理而改变了了,你就能够用这个功能。
比如,在book数据库中,我们能够隐藏publication_date,以防止它被编辑。
class BookAdmin(admin.ModelAdmin): list_display = (‘title‘, ‘publisher‘, ‘publication_date‘) list_filter = (‘publication_date‘,) date_hierarchy = ‘publication_date‘ ordering = (‘-publication_date‘,) **fields = (‘title‘, ‘authors‘, ‘publisher‘)**
Note:1. 上图中就没有改动publication日期的选项了。
2. 当一个用户用这个不包括完整信息的表单加入一本新书时,Django会简单地将publication_date设置为None,以确保这个字段满足null=True的条件。
还有一个经常使用的编辑页面自己定义是针对多对多字段的。 真如我们在book编辑页面看到的那样,`` 多对多字段`` 被展现成多选框。
尽管多选框在逻辑上是最适合的html控件,但它却不那么好用。 假设你想选择多项,你必须还要按下Ctrl键(苹果机是command键)。 尽管管理工具因此加入了凝视(help_text)。可是当它有几百个选项时,它依旧显得笨拙。
使用filter_horizontal
class BookAdmin(admin.ModelAdmin): list_display = (‘title‘, ‘publisher‘, ‘publication_date‘) list_filter = (‘publication_date‘,) date_hierarchy = ‘publication_date‘ ordering = (‘-publication_date‘,) **filter_horizontal = (‘authors‘,)**
刷新book编辑页面。你会看到Author区中有一个静止的javascript过滤器。它同意你检索选项。然后将选中的authors从Available框移到Chosen框,还能够移回来。
强烈建议针对那些拥有十个以上选项的`` 多对多字段`` 使用filter_horizontal。
这比多选框好用多了。 你能够在多个字段上使用filter_horizontal,仅仅需在这个元组中指定每一个字段的名字。
ModelAdmin类还支持filter_vertical选项
它像filter_horizontal那样工作,除了控件都是垂直排列。而不是水平排列的。 至于使用哪个,仅仅是个人喜好问题。
Note:filter_horizontal和filter_vertical选项仅仅能用在多对多字段 上, 而不能用于ForeignKey字段。
raw_id_fields选项
默认地,管理工具使用`` 下拉框`` 来展现`` 外键`` 字段。
可是。正如`` 多对多字段`` 那样,有时候你不想忍受因装载并显示这些选项而产生的大量开销。
比如,我们的book数据库膨胀到拥有数千条publishers的记录,以致于book的加入页面装载时间较久,由于它必须把每个publishe都装载并显示在`` 下拉框`` 中。
解决问题的办法是使用`` raw_id_fields`` 选项。
它是一个包括外键字段名称的元组,它包括的字段将被展现成`` 文本框`` 。而不再是`` 下拉框`` 。
class BookAdmin(admin.ModelAdmin): list_display = (‘title‘, ‘publisher‘, ‘publication_date‘) list_filter = (‘publication_date‘,) date_hierarchy = ‘publication_date‘ ordering = (‘-publication_date‘,) filter_horizontal = (‘authors‘,) **raw_id_fields = (‘publisher‘,)**在这个输入框中,你输入什么呢? publisher的数据库ID号。
考虑到人们通常不会记住这些数据库ID,管理工具提供了一个放大镜图标方便你输入。点击那个图标将会弹出一个窗体,在那里你能够选择想要加入的publishe。
关联对象inline
models:class Professor(People): job_title = models.CharField(max_length=150, blank=True, verbose_name=‘职称‘) class ResDir(models.Model): research_direction = models.TextField(blank=True, verbose_name=‘研究方向‘) professor = models.ForeignKey(Professor) # postgraduate = models.ForeignKey(Postgraduate)admin.py:
class inlineBase(admin.TabularInline): extra = 1 class ResDirInline(inlineBase): # 要重新启动runserver model = ResDir class ProfessorAdmin(admin.ModelAdmin): inlines = [ResDirInline, ][Django admin site(三)InlineModelAdmin]
嵌套关联对象nested inline
安装django-nested-inline
pip install django-nested-inline
使用
settings.py中的INSTALLED_APPS中加入nested_inline
INSTALLED_APPS = ( ... ‘nested_inline‘ )
Note:否则会出现找不到tabular-nested.html模板错误:
TemplateDoesNotExist at /admin/bigdata/lab/add/
admin/edit_inline/tabular-nested.html
# 实验室相关信息 class Lab(models.Model): introduction = models.TextField(null=True) achievement = models.TextField(null=True) class Directions(models.Model): research_direction = models.TextField(blank=True, verbose_name=‘研究方向‘) lab = models.ForeignKey(Lab) class Images(models.Model): images = models.ImageField(blank=True, verbose_name=‘图片‘) directions = models.ForeignKey(Directions)
class ImagesInline(NestedInlineBase): model = Images class DirectionsInline(NestedInlineBase): model = Directions inlines = [ImagesInline] class LabAdmin(NestedModelAdmin): inlines = [DirectionsInline] admin.site.register(Lab, LabAdmin)
[django-nested-inline 0.3.4]
[Nested Inline in Django Admin]
[Django Admin nested inline]
用户、用户组和权限
由于你是用超级用户登录的,你能够创建,编辑和删除不论什么对像。
管理工具有一个用户权限系统,通过它你能够依据用户的须要来指定他们的权限,从而达到部分訪问系统的目的。用户帐号应该是通用的、独立于管理界面以外仍能够使用。
但我们如今把它看作是管理界面的一部分。 [怎样把用户帐号与你的站点(不不过管理工具)集成在一起]
首先。这有一组三个布尔型标记:
-
活动标志。它用来控制用户是否已经激活。 假设一个用户帐号的这个标记是关闭状态,而用户又尝试用它登录时,即使password正确,他也无法登录系统。
-
成员标志,它用来控制这个用户能否够登录管理界面(即:这个用户是不是你们组织里的成员) 因为用户系统能够被用于控制公众页面(即:非管理页面)的訪问权限。这个标志可用来区分公众用户和管理用户。
-
超级用户标志。它赋予用户在管理界面中加入、改动和删除不论什么项目的权限。
假设一个用户帐号有这个标志,那么全部权限设置(即使没有)都会被忽略。
普通的活跃、非超级用户的管理用户能够依据一套设定好的许可进入。
管理界面中每种可编辑的对象(如:books)都有三种权限:创建 许可。编辑 许可和删除 许可。 给一个用户授权许可也就表明该用户能够进行许可描写叙述的操作。
当你创建一个用户时。它没有不论什么权限,该有什么权限是由你决定的。 比如,你能够给一个用户加入和改动publishers的权限,而不给他删除的权限。 请注意。这些权限是定义在模块级别上,而不是对象级别上的。这样的基于对象级别的权限设置比較复杂。能够在Django documentation中寻找答案。
Note:权限管理系统也控制编辑用户和权限。 假设你给某人编辑用户的权限,他能够编辑自己的权限,这样的能力可能不是你希望的。 赋予一个用户改动用户的权限。本质上说就是把他变成一个超级用户。
你也能够给组中分配用户。
一个 组 简化了给组中全部成员应用一套许可的动作。 组在给大量用户特定权限的时候非常实用。
何时、为什么使用管理界面?
Django的管理界面对非技术用户要输入他们的数据时特别实用;其实这个特性就是专门为这个 实现的。
在Django最開始开发的新闻报道的行业应用中,有一个典型的在线自来水的水质专题报道 应用,它的实现流程是这种:
-
负责这个报道的记者和要处理数据的开发人员碰头。提供一些数据给开发人员。
-
开发人员环绕这些数据设计模型然后配置一个管理界面给记者。
-
记者检查管理界面,尽早指出缺少或多余的字段。 开发人员来回地改动模块。
-
当模块认可后,记者就開始用管理界面输入数据。 同一时候,程序猿能够专注于开发公众訪问视图和模板(有趣的部分)。
换句话说,Django的管理界面为内容输入人员和编程人员都提供了便利的工具。
除了数据输入方面,管理界面在以下这些情景中也是非常实用的:
1. 检查模块* :当你定义好了若干个模块。在管理页面中把他们调出来然后输入一些虚假的数据,这是相当实用的。 有时候,它能显示数据建模的错误或者模块中其他问题。
2. 管理既得数据* :假设你的应用程序依赖外部数据(来自用户输入或网络爬虫)。管理界面提供了一个便捷的途径。让你检查和编辑那些数据。
你能够把它看作是一个功能不那么强大,可是非常方便的数据库命令行工具。
3. 暂时的数据管理程序* :你能够用管理工具建立自己的轻量级数据管理程序,比方说开销记录。 假设你正在依据自己的,而不是公众的须要开发些什么。那么管理界面能够带给你非常大的帮助。 从这个意义上讲,你能够把它看作是一个增强的关系型电子表格。
最后一点要澄清的是: 管理界面不是终结者。 过往很多年间,我们看到它被拆分、改动成若干个功能模块。而这些功能不是它所支持的。它不应成为一个* 公众* 数据訪问接口,也不应同意对你的数据进行复杂的排序和查询。 正如本章开头所说。它仅提供给可信任的管理员。
请记住这一点,它是有效使用管理界面的钥匙。
from:http://blog.csdn.net/pipisorry/article/details/45079751
以上是关于Django项目实践4 - Django网站管理(后台管理员)的主要内容,如果未能解决你的问题,请参考以下文章