大家好，这是皮爷给大家带来的最新的学习Python能干啥？之Django教程，从零开始，到最后成功部署上线的项目。这一节，我们将对顶部的Navbar动手，将其优化。
Peekpa.com的官方地址：http://peekpa.com
皮爷的每一篇文章，都配置相对应的代码。这篇文章的代码Tag是Post_022
Narbar说的是这个东西：
上一节，我们对我们的页面进行了整体的优化，其中提到了页面顶部的Narbar的实现，当时，我们在文章里说了有两种方法：
- 第一种是直接写死a标签
- 第二种则是在后台写好管理程序，前端每次请求的时候，后端把标签放到变量里面，然后传给前端
这两种方式有利有弊：
- 方式一写死，灵活性会很差；
- 方式二写的活，但是代码量就会上去。
有没有一种好的方式既能灵活，又能偷懒呢？
答案是没有，不过，在这里，皮爷准备用一种“一半写死，一半写活”的方式来修改我们的Navbar，即：
- 常用的标签，准备写死处理，比如首页，文章列表；
- 剩下的标签，打算写活，这样日后网站要扩展或者关闭服务，都可以动态的通过后台来操作，不需要重新发办修改代码。
随着功能的开发，我们还需要做的另一件事儿就是首页的整合。为啥要整合首页啊？是因为我们的首页现在变得越来越复杂，已经不再是之前简简单单的首页了，为了日后能够更好的维护，我们需要将首页以及一些公共的功能抽取出来，重新整合。
那，这种方式怎么做呢？？
写死的部分
我们说了，针对常用的部分，我们做写死处理。
需要写死的部分，要满足条件：
- 常用
- 日后不打算大型修改
目前满足的就是首页还有文章。因为这两个分类，从网站长期来看，不需要修改。所以这部分，可以直接写死a标签。
{% url 'post:index' as index %}
{% url 'post:post_list' as post_list %}
<li class="nav-item mr-4">
<a class="nav-link {% if request.path == index %}active{% endif %}" href="{{ index }}">首页</a>
</li>
<li class="nav-item mr-4">
<a class="nav-link {% if request.path == post_list %}active{% endif %}" href="{{ post_list }}">文章</a>
</li>
写活的部分
剩下的板块内容，我们就可以写活了。通过后台写的管理界面，来管理前端页面需要展示的东西。这个开发过程和第20篇写的友链开发很像。开发流程都很像，这里就不对开发流程做过多的介绍了。
我们就来简单介绍一些关键的技术点吧。
模型创建
既然我们要动态管理标签，那么我们就需要创建一个应用，在应用的models.py文件里面创建模型。这里我们就创建一个basefunction应用，然后，针对Navbar的标签创建模型：
class NavbarItem(models.Model):
STATUS_NORMAL = 1
STATUS_DELETE = 0
STATUS_DRAFT = 2
STATUS_ITEMS = (
(STATUS_NORMAL, '正常'),
(STATUS_DELETE, '删除'),
(STATUS_DRAFT, '草稿'),
)
SHOW_PAGE_HOMEPAGE = 0
SHOW_PAGE_CMS = 1
SHOW_PAGE_FORUM = 2
SHOW_PAGE_ITEMS = (
(SHOW_PAGE_HOMEPAGE, '首页'),
(SHOW_PAGE_CMS, 'CMS'),
(SHOW_PAGE_FORUM, '论坛'),
)
name = models.CharField(max_length=30)
show_name = models.CharField(max_length=30)
url_path = models.CharField(max_length=100)
create_time = models.DateTimeField(auto_now_add=True)
show_page = models.PositiveIntegerField(default=SHOW_PAGE_HOMEPAGE, choices=SHOW_PAGE_ITEMS)
status = models.PositiveIntegerField(default=STATUS_DRAFT, choices=STATUS_ITEMS)
这里我们又新增了一个显示页面，用来控制这个标签在哪里显示。
然后在settings.py里面的INSTALLED_APPS配置'apps.basefunction'，这样就表面应用以及安装到了框架里，接着执行$ makemigrations和$ migrate两条命令，将模型映射到数据库中。
后台管理的开发
后台管理还是和之前一样，在cms下创建navitem，然后是管理页面和发布页面。当html页面创建好之后，就要编写视图函数，最后页面基本长这两个样子，管理页面：
发布修改页面：
接着我们就是要写视图函数，分别是增删改查。具体的做法都在第20讲里面的友链开发中，详细的说了，这里就不多说了。
最后别忘了配置url：
path("dashboard/navitem/manage", views.navitem_manage_view, name="navitem_manage_view"),
path("dashboard/navitem/publish", views.navitem_publish_view, name="navitem_publish_view"),
path("dashboard/navitem/add", NavItemView.as_view(), name="navitem_add"),
path("dashboard/navitem/edit", NavItemEditView.as_view(), name="navitem_edit"),
path("dashboard/navitem/delete", NavItemDeleteView.as_view(), name="navitem_delete"),
最后实现了增删改查，我们接下来就是要在前端来展示数据了。
前端展示
既然是可以配置的，那么我们就需要在有Navbar的视图函数里面，把我们的Navbar读取出来，然后输送给前端。
由于之前我们把post还有list页面，都写在了post应用下，这样耦合度太高，我们需要将原来的index视图函数还有post list视图函数作为长期公用的方法，放到basefunction应用里面，所以，我们顶部的Navbar视图函数也应该和这些在一起：
{% if navitem_list %}
{% for navitem in navitem_list %}
<li class="nav-item mr-4">
<a class="nav-link {% if request.path == navitem.url_path %}active{% endif %}" href="{{ navitem.url_path }}">{{ navitem.show_name }}</a>
</li>
{% endfor %}
{% endif %}
我们在app/base下创建一个common_view.py文件，将之前获取阅读文章的逻辑；友链的逻辑全部放到这里。再加上我们的获取顶部Navbar的逻辑：
def get_read_most_post():
read_post = Post.objects.all().order_by('-read_num')
if len(read_post) > 5:
read_post = read_post[:5]
context = {
'read_post': read_post
}
return context
def get_exchange_link():
exchange_link = ExchangeLink.objects.filter(status=ExchangeLink.STATUS_NORMAL)
context = {
'exchange_link': exchange_link
}
return context
def get_navbar_item_homepage():
navitem = NavbarItem.objects.filter(status=NavbarItem.STATUS_NORMAL, show_page=NavbarItem.SHOW_PAGE_HOMEPAGE)
context = {
'navitem_list': navitem
}
return context
接下里就是把index搬到basefunction应用里面：
def index(request):
top_post = Post.objects.filter(is_main_page=True).order_by('-priority')
list_post = Post.objects.filter(is_main_page=False)
context = {
'top_post': top_post,
'list_post': list_post
}
context.update(get_read_most_post())
context.update(get_exchange_link())
context.update(get_navbar_item_homepage())
return render(request, 'post/index.html', context=context)
basefunction/urls.py里面配置好url映射：
app_name = "base"
urlpatterns = [
path("", views.index, name="index"),
]
同样，别忘了在文章列表页里面，把nav_item的数据传给前端。
这个时候，就完事儿了。我们注意到，之前我们在创建的NavItem的地址是 /list/，然后呢，我们这个时候打开首页看一下：
然后点击我们的动态配置002：
发现他和文章标签都变白了，说明class里面添加了active类。
接着，我们再来后台，将动态配置002的状态设置成删除：
这个时候，再返回前端看一眼：
发现页面没有了！！是不是很神奇！！
通过这样简单的操作，我们就能控制前端页面的展示内容了。
技术总结
最后总结一下，
Navbar的最优写法：
- Navbar既能写死，也能写活，所以，我们选择了一种半死半活的写法，即将常用的内容写死，不常用的内容通过后台配置写活；
- 创建basefunction，将公共功能抽离出来，创建NavItem模型，并开发；
- 开发NavItem的管理，和20讲的友链开发流程一模一样；
- 开发完成之后，就可以通过后台的控制，来实现前端页面展示内容的变化；
- 完毕。
获取代码的唯一途径：关注『皮爷撸码』，回复『代码』即可获得。
长按下图二维码关注，如文章对你有启发，欢迎在看与转发。
