django是前端还是后端 (django框架主要用来做什么)
本文目录导航：
django是前端还是后端
展示机型：华为MateBook X 系统版本：win10 APP版本：django3.0 django是用在前端。
Django是一个基于Python的Web运行框架。
它与Python的另外一个Web框架Flask最大的区别是，它奉行蕴含一切的哲学。
该理念即为创立Web运行所需的通用性能都应该蕴含到框架中，而不应存在于独立的软件包中。
例如身份验证、URL路由、模板系统、对象相关映射（ORM）和数据库迁徙等性能都已蕴含在Django框架中。
只管看上去失去了一些弹性，但是却可以在构建网站的时刻愈加有效率。
django如何用前端渲染(django前端还是后端)
求助django成功前端页面检索性能的代码设咱们的django博客运行有如下的文章模型：
#题目
title=(max_length=70)
#注释
#其余属性
def__str__(self):
先看到第1步，用户在搜查框输入搜查关键词，因此咱们要在博客上为用户提供一个搜查表单，html表单代码大略像这样：
formmethod=getaction=/search/
{%csrf_token%}inputtype=searchplaceholder=搜查required
buttontype=submit搜查/button/form
特意留意在form标签下有一个{%csrf_token%}，这是django用来进攻跨站恳求伪造（CSRF）攻打的机制。
假设不知道什么是CSRF的话也没有相关，只需记住在经常使用django时，前端的表单代码里必定要加上{%csrf_token%}。
用户输入了搜查关键词并点击了搜查按钮后，数据就被发送给了django后盾主机。
表单的action属性的值为/search/，标明用户提交的结果将被发送给/search/这个URL。
咱们为这个URL绑定一个django视图函数，在这个视图函数里成功前面第2步提到的环节。
假定咱们把视图函数的代码写在blog/里：
blog/(request):
error_msg=
error_msg=请输入关键词
returnrender(request,blog/,{error_msg:error_msg})
post_list=(title__icontains=q)
returnrender(request,blog/,{error_msg:error_msg,
post_list:post_list})
首先咱们经常使用(q)失掉到用户提交的搜查关键词。
用户经过表单提交的数据django为咱们保留在里，这是一个相似于Python字典的对象，所以咱们经常使用get方法从字典里取出键q对应的值，即用户的搜查关键词。
这里字典的键之所以叫q是由于咱们的表单中搜查框input的name属性的值是q，假设修正了name属性的值，那么这个键的称号也要相应修正。
接上去咱们做了一个小小的校验，假设用户没有输入搜查关键词而提交了表单，咱们就无需口头查问，而是渲染一个失误页面揭示用户请输入关键词。
假设用户输入了搜查关键词，咱们就经过filter方法从数据库里过滤出合乎条件的一切文章。
这里的过滤条件是title__icontains=q，即title中蕴含（contains）关键字q，前缀i示意不辨别大小写。
这里icontains是查问表白式（Fieldlookups），其用法是在模型须要挑选的属性前面跟上两个下划线。
django内置了很多查问表白式，倡导过一遍django官网留个印象，了解每个表白式的作用，以后碰到相关的需求就可以极速定位到文档查问其用途：Fieldlookups
接上去就是渲染搜查结果页面，显示合乎搜查条件的文章列表，上方是一个模板的繁难示例：
{%iferror_msg%}p{{error_msg}}/p{%endif%}
{%forpostinpost_list%}div
在这里显示文章的相应消息/div{%empty%}divclass=no-post
没有搜查到合乎条件的文章/div{%endfor%}
有了视图函数后记得把视图函数映射到相应了URL，前面咱们表复数据提交的URL为/search/，因此将视图函数search绑定到该URL上。
#其余url性能
url(r^search/$,,name=search),]
功败垂成！
Django框架中path及re_path中name参数的经常使用和模板渲染（八）name参数可以给一个婚配的url地址取名字，普通用于模板,也可以经常使用reverse启动页面重定向。
1、为APP中的books外面的（给url取个名字）
2、为APP中books外面的（redirect是重定向,reverse是将url的name解析成url自身的函数）
1、name参数可以给这个url取一个适宜的名字。
经过给url取名字，以后在view或许模板中经常使用这个URL，就只须要经过这个名字就可以了。
这样做的要素是防止url的规定更改，会造成其余中央用了这个url的中央都须要更改，但是假设取名字了，就不要做任何改变了。
2、留意事项：
1、模板放在哪?
2、在名目主目录中启动模板门路性能；将咱们的设置好的寄存html模板的templates目录门路参与到DIRS中。
留意：reverse方法外面也可以有kwargs参数，间接将参数传给被reverse解析后要跳转的url门路中的捕捉参数，来到达传参的成果。
怎样用django写好代码的关键性Django代码留意
1、模板标签外面extend和include是抵触的，有了extend，include不可失效，要素：是底层渲染独立机制设计造成。
2、#coding:utf-8这句只要放在代码文件第一行能力失效，放在注释字符串前面或许会失效。
3、由于前端开展而造成的Post恳求Rest化和Django原生的技术设备层简化还有事务封装前移，由此发生的结果是业务层齐全可以放在views外面。共事Restful化的好处就是可以把跨业务模块调用放在前端，保障了后端模块之间的正切
4、有用户自生成富文本内容的页面上最好不要搁置带XSRF的POST表单，前者或许会窃取后者的Token消息。
5、在template外面的==这一类比拟逻辑运算符号两边必定有空格，否则影响模板解析
6、_valid外部逻辑中的Clean_data处置中抛出的意外不会向外传递，只会变成_valid()前往false.
7、Django的业务层和View层怎样切分这个疑问，一个繁难的方法就是给业务层传递什么层级的参数，团体感觉传递验证过的form比拟适宜。
8、多级ifelse的两个简化技巧：1是间接用except处置；2是该半路return的间接return掉,这样做只管不合乎环节编程函数设计准则，但是代码相对繁复了很多。
9、Ubuntu消费环境下不能PrintUnicode中文，否则会造成error.
10、由于DJango的500机制和事务机制，所以Django的View层对意外处置代码的依赖比拟弱。
11、modelform定义：没有在前端页面发生的字段，必定要exclude掉或许Null了，不过Null会影响自动值，所以最好的方法是Exclude掉，否则即使blank掉，也会造成form存储时出错。
由于表单中字段不发生会把自动值笼罩成Null。
比exclude更繁难的定义模式是定义fields元消息，这样model参与不用的字段不用跑来从新降级form定义
12、数据库存时区性数据的格局化显示必定要放在template外面用date之类的过滤器操作，假设用datetime的striftime间接格局化，会造成时区性数据失落，进去的期间成了格林威治期间值了，假设在代码中strifttime处置,可以先用方法处置一下，这样进去的期间才是反常的
13、Django调试中的一个疑问：妇孺皆知，runserver启动，改变代码，服务会重启，但是改变自定义标签代码，服务是不会重启的。
14、form验证的errors在比拟旧的版本外面是没有文本消息，前一段期间看文档，发现新版本有对errors有所增强，比拟好用的比如as_json()和as_text()，两个方法，我在比拟旧的版本中是自己写个函数对errors对象做解析生成反应文本消息。
15、ManyToMany字段的through不能addorremove，为了裁减性的思考，倡导自动都加上through，可认为两边相关表加个date_added字段，顺便都加上unique_together解放，不过用through是有毛病的：写操作略费事。
那么假设你没加through，预备改成加through的，应该怎样最小改变的操作哪，应该是先把这个ManyToMany字段删除掉，并且migrate失效，而后再加一个有through的ManyToMany字段，当然了后盾的数据还的备份新失效一次性。
这应该算是目前DjangoMigration个性的一个毛病。
[Django]如何在Django中经常使用前端工具链
Django最大的无余在于其落后的前端工具链。
如今前端开发简直必备的包治理器（例如npm,yarn）以及工程化必备的webpack工具链，Django却不允许。
Django开发的上班流中，后端的包治理可以用pip，而前端的包只能手动治理。
所以，我最近的工程名目中，已不再经常使用Django提供的前端模块，仅仅把它当作API主机。
这确实很遗憾，由于Django的template引擎也有一些易用的个性，如此放弃，真的有点不舍。
那么有没有或许联合二者的优势呢？
经过一番探求，网上给出最靠谱的答案就是应用django-webpack-loader和webpack-bundle-tracker这两个插件。
其原理是webpack-bundle-tracker能够输入webpack的编译环节以及结果。
django-webpack-loader插件则是Django和webpack之间的桥梁，应用上方的编译结果，智能加载webpack打包后的静态文件。
须要用webpack生成的静态文件时，就在template上方经常使用上方一段模板言语，能够智能成功静态文件的注入。
繁难的试了试，应该能够到达我想要的成果，明日有期间再钻研。
Django媒体文件URL的性能在Django中经常须要性能图片、视频等表态文件，在性能时较为复杂，这里纪录一下：
在文件尾部参与以下目录，用于寄存上行的文件
在models中写上image字段其中%Y代表年，%m代表月，blank=True代表可认为空。
当上行文件时，代表上行到image目录下，以以后年月子目录的文件夹中。
image=(upload_to=image/%Y/%m,blank=True)
其中src中的{{MEDIA_URL}}会在模板中渲染为第一步中的/media/
假设您想在模板中经常使用{{MEDIA_URL}}，请在“模板”的“context_processors”选项中参与_。
经过以上步骤，基本上可以在前端反常渲染出结果了，但还须要给图片参与一个URL以反常显示。
第一行为引入静态文件的serve，第二行为导入工程性能文件中的MEDIA_ROOT
在url中参与：
经常使用django搭建团体博客算做前端还是后端?
在经常使用Django搭建团体博客时，触及前端与后端的辨别，详细取决于名目标结构和需求。
繁难状况下，Django自带的模板引擎可以同时处置前端和后端性能（前后端不分别），适宜极速构建小型名目。
但是，为了顺应现代开发趋向，名目或许须要成功前后端分别，即前端驳回Vue、React等现代框架构建，专一于界面展现与用户交互，而Django则担任提供API接口，成功数据处置与业务逻辑。
简而言之，前端关键担任展现内容与交互体验，包括网页、移动运行中的界面元素。
后端则承当数据处置和业务逻辑，例如，用户点击按钮触发的数据查问等操作，理论由后端处置并前往数据给前端展现。
因此，关于团体博客名目，从不分别的初始阶段开局，学习HTML、CSS、JavaScript等前端技术是必要的。
随着名目复杂度的参与，逐渐引入前后端分别架构，可以优化系统的灵敏性和可保养性。
phper