本教程上接教程6。 我们继续网页投票应用,并将重点定制Django自动生成的管理后台站点,这是我们在教程2中首先探讨的。
只需使用admin.site.register(Question)
注册Question
模型,Django就能构造一个默认的表单表示。 通常,你会想要自定义管理界面中表单的外观和功能。 你可以通过在注册对象的时候告知Django一些你想要的选项来完成。
让我们看看如何通过重新排序编辑表单上的字段来实现。 将admin.site.register(Question)
行替换成:
from django.contrib import admin
from .models import Question
class QuestionAdmin(admin.ModelAdmin):
fields = ['pub_date', 'question_text']
admin.site.register(Question, QuestionAdmin)
任何时候你需要更改模型的管理选项,你将遵循此模式 — 创建一个模型管理类,然后将其作为第二个参数传递给admin.site.register()
。
上面那特定的更改,使得“Publication date”字段排在“Question”字段前面:
仅有两个字段不会令你印象深刻,但是当管理有许多字段的表单时,选择一个直观的排序方式是一个重要而实用的细节。
说到有许多字段的表单,你可能想把表单分割成字段集:
from django.contrib import admin
from .models import Question
class QuestionAdmin(admin.ModelAdmin):
fieldsets = [
(None, {'fields': ['question_text']}),
('Date information', {'fields': ['pub_date']}),
]
admin.site.register(Question, QuestionAdmin)
fieldsets
中每个元组的第一个元素是字段集的标题。
以下是我们的对象表单现在的样子:
现在,Question管理界面看起来已经很好了,让我们再来稍微调整一下“变更列表”界面 —— 该界面显示系统中所有的Question。
下面是目前为止它的样子:
默认地,Django显示每个对象的str()
返回的内容。 但有时如果我们能显示个别的字段将很有帮助。 我们使用list_display
选项来实现这个功能,它是一个要显示的字段名称的元组,在对象的变更列表页面上作为列显示:
class QuestionAdmin(admin.ModelAdmin):
# ...
list_display = ('question_text', 'pub_date')
为了方便查看,我们还添加了教程2中的was_published_recently()
方法:
class QuestionAdmin(admin.ModelAdmin):
# ...
list_display = ('question_text', 'pub_date', 'was_published_recently')
现在,Question变更列表页面看起来就像如下所示:
你可以点击其中一列的头部来让列表按照这列的值来进行排序 —— 除了was_published_recently
这列的头部,因为Django不支持按照随便一个方法的输出进行排序。 另请注意,默认情况下,was_published_recently
的列标题是方法的名称(下划线替换为空格),每行包含输出的字符串表示形式。
通过给这个方法(在polls/models.py
)提供一些属性改进,如下所示:
class Question(models.Model):
# ...
def was_published_recently(self):
now = timezone.now()
return now - datetime.timedelta(days=1) <= self.pub_date <= now
was_published_recently.admin_order_field = 'pub_date'
was_published_recently.boolean = True
was_published_recently.short_description = 'Published recently?'
关于这些方法属性的更多信息,请参见 list_display
。
再次编辑你的polls/admin.py
文件来改进Question
变更列表页面:使用list_filter
来添加过滤器。 将下面这行添加进QuestionAdmin
:
list_filter = ['pub_date']
这行代码添加一个“Filter”侧边栏,可以使人们通过pub_date
字段对变更列表进行过滤:
显示的过滤器类型取决于你所使用的字段类型。
因为pub_date
是一个DateTimeField
,Django知道提供适当的过滤器选项:“任何日期”,“今天”,“过去7天”,“这个月”,“这年”。
这样看起来有些像我们想要的样子了。 让我们再来添加一些搜索功能:
search_fields = ['question_text']
这行代码在变更列表的顶部添加了一个搜索框。 当有人将搜索的内容输入搜索框,Django将在question_text
字段中进行搜索。 你可以使用任意数量的字段进行搜索 —— 但由于它在后台使用LIKE
进行查询,所以限制搜索字段的数量会使数据库查询更加容易。
现在又是一个好时机来告诉你变更列表界面提供方便的分页功能。 默认每页显示100条记录。 Change list pagination
、search boxes
、filters
、date-hierarchies
和column-header-ordering
都将按照你设想的那样工作。
很明显,每个管理页面的顶部都有“Django administration”不太合适。 它仅仅起到了占位符的作用。
它可以用Django的模板系统轻松改变。 Django的管理站点是用Django自己制作出来的,它的界面代码使用的是Django自己的模板系统。
在你项目的文件夹内(包含 manage.py
的目录)创建一个templates
目录。 Templates可以放在你的文件系统中Django所能访问到的任何地方。 (运行Web服务器的用户即是运行Django的用户)。 然而,把模板放在项目目录下会是一个值得提倡的、应该遵循的约定。
打开你的配置文件(记住是mysite/settings.py
)在TEMPLATES
设置中添加一个DIRS
选项:
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [os.path.join(BASE_DIR, 'templates')],
'APP_DIRS': True,
'OPTIONS': {
'context_processors': [
'django.template.context_processors.debug',
'django.template.context_processors.request',
'django.contrib.auth.context_processors.auth',
'django.contrib.messages.context_processors.messages',
],
},
},
]
DIRS
是加载Django模板时要检查的文件系统目录的列表;它是一个搜索路径。
组织模板
就像静态文件一样,我们可以将所有的模板都放在一个大的模板目录中,并且工作得很好。 但是,属于特定应用程序的模板应该放在该应用程序的模板目录中(例如polls/templates
)而不是项目的(templates
)。 我们将在reusable apps tutorial 中更详细地讨论为什么我们这样做。
现在,在templates
下创建一个名为admin
的文件夹,然后从Django安装的原目录下(目录为django/contrib/admin/templates
)将模板页面的源文件admin/base_site.html
拷贝到这个文件夹里。
Django的源文件在哪里?
如果你找不到Django源文件在你系统上的位置,运行如下命令:
$ python -c "import django; print(django.__path__)"
然后,只需编辑该文件并替换{{ site_header|default:_('Django administration') }}
(包括花括号)为你认为合适的自己站点的名称。 编辑完成后应该类似下面的代码片段:
{% block branding %}
<h1 id="site-name"><a href="{% url 'admin:index' %}">Polls Administration</a></h1>
{% endblock %}
我们使用这个例子来教你如何覆盖模板。 在实际项目中,你可能会使用 django.contrib.admin.AdminSite.site_header
属性来更简单地实现这个自定义功能。
模板文件包含许多类似{% block branding %}
和{{ title }}
这样的文本。 {{
和{%
是Django模板语言的一部分。 当Django呈现admin/base_site.html
时,将会评估此模板语言以生成最终的HTML页面,就像我们在Tutorial 3中看到的那样。
注意任何Django管理站点的默认模板都可以被覆盖。 想要覆盖一个模板文件,只需要做和覆盖base_site.html
相同的操作就行 —— 将它从默认的目录拷贝到你自定义的目录中,然后修改它。
细心的读者将会问:由于DIRS
默认是空的,Django是怎么找到默认的管理站点模板的? 答案是,由于APP_DIRS
设置为True
,Django会自动地在每个应用包下面查找一个templates/
子目录,留作备用。(别忘了,django.contrib.admin
也是一个应用)。
我们的投票应用并不是太复杂,不需要自定义管理站点模板。 但是如果它变得更加复杂而且为了一些功能需要修改Django的标准管理站点模板,那么与修改项目中的模板相比,修改应用中的模板将是更明智的选择。 使用这种方式,你可以在任何新项目中使用投票应用,并且可以确保Django将找到它需要的自定义模板文件。
更多关于Django如何找到它的模板文件的信息,请查看 模板加载 。
与上面类似的是,你可能想自定义Django管理站点首页面的外观。
默认情况下,首页面显示所有位于INSTALLED_APPS
中且已经使用管理站点应用注册过的应用,这些应用按照字母顺序进行显示。 你可能想在布局上做出重大改变。 毕竟,首页面可能是管理站点中最重要的页面,并且它应当易用。
需要自定义的模板文件是 admin/index.html
。 (与上一节中的admin/base_site.html
相同 - 将其从默认目录复制到您的自定义模板目录)。 编辑这个文件,你将看到它有一个叫做app_list
的变量。 这个变量包含安装的所有Django应用。 你可以选择不像默认模板中那样使用它,而是以你认为最好的方式硬编码链接到每个对象自己的管理页面。
初学者教程结束于此。 在这期间,你可能想要在 下一步 中了解文档的结构和查找相关信息方法。
如果你熟悉Python 打包的技术,并且对如何将投票应用制作成一个“可重用的应用”感兴趣,请看 进阶教程: 如何编写可重用的应用 。
2017年9月6日