重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
Flask 是一种具有平缓学习曲线和庞大社区支持的微框架,利用它可以构建大规模的web应用。是搭建社区的神器之一。
创新互联是一家集网站建设,浦北企业网站建设,浦北品牌网站建设,网站定制,浦北网站建设报价,网络营销,网络优化,浦北网站推广为一体的创新建站企业,帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿,时刻以成就客户成长自我,坚持不断学习、思考、沉淀、净化自己,让我们为更多的企业打造出实用型网站。
利用它可以构建大规模的web应用。学习上手Flask非常轻松,但要深入理解却并不容易。本书从一个简单的Flask应用开始,通过解决若干实战中的问题,对一系列进阶的话题进行了探讨。书中使用MVC(模型-视图-控制器)架构对示例应用进行了转化重构,以演示如何正确地组织应用代码结构。有了可扩展性强的应用结构之后,接下来的章节使用Flask扩展为应用提供了额外的功能,包括用户登录和注册、NoSQL查询、REST API、一套后台管理界面,以及其他特性。然后,你会学到如何使用单元测试,保障代码持续按照正确的方式工作,避免极具风险的猜测式编程。
一个简单的Flask 项目入手,由浅入深地探讨了一系列实战问题,包括如何使用SQLAlchemy 和Jinja 等工具进行Web 开发;如何正确地设计扩展性强的Flask 应用架构和搭建MVC 环境;对于各种NoSQL 数据库的特性,何时应该、何时不应该及如何使用它们;通过使用Flask 扩展快速实现用户的身份系统、RESTful API、NoSQL查询、后台管理等功能;如何创建自己的扩展;使用Celery 编写异步任务,使用pytest 进行单元测试等;最后介绍了如何部署上线,包括使用自己搭建的服务器或使用各种云服务,以及如何权衡和选择这些不同的解决方案。
InternetExplorer(包含傲游,世界之窗等和IE使用同一内核的浏览器) 工具-Internet 选项-浏览历史记录一栏点“设置”-查看文件
浏览器自动打开了IE的缓存文件夹(临时文件夹)。
(1)Flask
Flask确实很“轻”,不愧是Micro Framework,从Django转向Flask的开发者一定会如此感慨,除非二者均为深入使用过
Flask自由、灵活,可扩展性强,第三方库的选择面广,开发时可以结合自己最喜欢用的轮子,也能结合最流行最强大的Python库
入门简单,即便没有多少web开发经验,也能很快做出网站
非常适用于小型网站
非常适用于开发web服务的API
开发大型网站无压力,但代码架构需要自己设计,开发成本取决于开发者的能力和经验
各方面性能均等于或优于Django
Django自带的或第三方的好评如潮的功能,Flask上总会找到与之类似第三方库
Flask灵活开发,Python高手基本都会喜欢Flask,但对Django却可能褒贬不一
Flask与关系型数据库的配合使用不弱于Django,而其与NoSQL数据库的配合远远优于Django
Flask比Django更加Pythonic,与Python的philosophy更加吻合
(2)Django
Django太重了,除了web框架,自带ORM和模板引擎,灵活和自由度不够高
Django能开发小应用,但总会有“杀鸡焉用牛刀”的感觉
Django的自带ORM非常优秀,综合评价略高于SQLAlchemy
Django自带的模板引擎简单好用,但其强大程度和综合评价略低于Jinja
Django自带ORM也使Django与关系型数据库耦合度过高,如果想使用MongoDB等NoSQL数据,需要选取合适的第三方库,且总感觉Django+SQL才是天生一对的搭配,Django+NoSQL砍掉了Django的半壁江山
Django目前支持Jinja等非官方模板引擎
Django自带的数据库管理app好评如潮
Django非常适合企业级网站的开发:快速、靠谱、稳定
Django成熟、稳定、完善,但相比于Flask,Django的整体生态相对封闭
Django是Python web框架的先驱,用户多,第三方库最丰富,最好的Python库,如果不能直接用到Django中,也一定能找到与之对应的移植
Django上手也比较容易,开发文档详细、完善,相关资料丰富
flask本身相当于一个内核,几乎其他所有的功能都要用到扩展:邮件扩展Flask-Mail,用户认证Flask-Login,数据库Flask-SQLAIchemy等,都需要用第三方扩展来实现。flask没有默认使用的数据库,可以根据自己的选择MySQL或者nosql。其WSGI工具箱采用Werkzeug的路由模块,模板引擎则使用jinjia2。这两个也是flask框架的核心。
常用扩展
框架对比:
总结:至于选什么框架-轻重对比-框架选择上:
flask:后期业务升级迭代,更换技术方案,自由,灵活,高度定制。
Django:快速实现业务,不考虑技术选型,越简单直接越好。
Tornado:tornado走的是少而精的方向,注重的是性能优越,它最突出的是异步非阻塞的设计方式:HTTP服务器,异步编程,websockets。
没看form有关的源码,但是应该是这样的∶
首先,你得理解像flask这种MVC(或者说MTC)的基本运行机制。
- 对于flask的view,你得知道wsgi协议(如果不清楚,请自行Google之)。
更底层(逻辑上的底层)的HTTP utils(flask用的是werkzeug)将client端的HTTP requests等进行parse,并且将其构建为wsgi的environment(包含了request及其他信息)。
wsgi
server在process请求的过程是:根据wsgi协议构建environ,将其传入flask app
instance(这个即为flask框架实现的wsgi app),flask app
instance用这个environ和自己的``start_response``
method(这个也是uwsgi协议规约)完成请求处理并response。
flask有一个线程级(或greenlet)的request对象。在真正process response之前,将environ丢到这个request对象里,之后这个request跟着你的那个线程就成为了默契的炮友~~直至response完成或线程完蛋。
views里面的那一坨坨的route的作用是啥捏?这个就是url routing了,就是我在你的站点上点了一个特定的url,flask要如何满足你。你得说出你想要的东西吧。
那么views是什么时候用到呢?废话,当然还是在接收并理解请求之后到响应之前。
好
了,flask app instance在处理你的需求的时候从request对象里拿到了你请求的url,这个就相当于一把key,然后app
instance根据这个key去views里找到了对应的锁(你想要的处理逻辑,就是views里的route下面的function),这个锁啊,她
一旦被打开了,满足你需求的时刻也就快了 ~ ~
P.S. 至于如何匹配到这个锁的呢,这个就是url mapping了,就是一堆正则匹配(别小看这个,如果你用过flask的blueprint,你会明白写这么个mapping也是件爽hi了的事情咯)
- model controller呢?
你的需求其实就是要flask给你response,response其实呢就是数据(不管是RESTFUL API还是template形式,都是你撸出的data)。
数据这坨翔实怎么来的呢?就是你从数据库(广义,包括sql nosql db,内存级缓存,磁盘文件等等等等)拿到的,至于data的来源嘛,可能是你自己插的,或者是从别的地方哭着要来的。
model
就是干这活的,只不过它比较抽象,将数据库操作转成了对Python对象的操作(这个就是大名鼎鼎的ORM,其实并没有什么卵用,ORM写多了你连查询优
化都忘了,如果你有比较高的performance需求也有很多时间,就自己撸高效检索方案吧,我没少被这玩意儿坑%_%)。
controller这玩意儿你其实可以不要,不过为了做逻辑分离,让你撸业务撸的漂亮点儿还是用它吧。
OK,说了这么多,不知道有没有人能看懂,如果没看懂,让我思考会儿吧 ~ ~
========================================================================
简而言之呢,你用flask作application的时候,MVC各司其职堆好你产生data的逻辑即可,其它你一概不用管。
靠,终于可以回到你的问题上了:
先看下Form这玩意儿:
from flask.ext.wtf import Form
from wtforms import StringField, SubmitField
from wtforms.validators import Required
class NameForm(Form):
name = StringField('What is your name?', validators=[Required()])
submit = SubmitField('Submit')
这就是一个类而已,和model里面的那些玩意儿没本质区别,也都是一个映射关系。model是将数据库啥的和Python对象映射;Form是将HTML表单(form)和这个从flask.ext.wtf.Form及其子类映射。
再来看看这玩意儿:
1 @app.route('/', methods=['GET', 'POST'])
2 def index():
3 name = None
4 form = NameForm()
5 if form.validate_on_submit():
6 name = form.name.data
7 form.name.data = ''
8 return render_template('index.html', form=form, name=name)
首先来分析一下执行过程:
哎呀,这个只是个route嘛,它哪有执行过程。
执行是由app instance做的嘛,好吧,其实它是被app instance做的。
在
展开之前看一下route后面那个 methods=['GET',
'POST']。这玩意的意思是说,当我遇到有与``index``(即上面route下面的那个index)匹配的的请求时,我可以用GET或者
POST方法,其他的像PUT、DELETE等HTTP verb我不让你丫玩儿。
当你把你的这个flask应用deploy到web server或者在本地run test server的时候,你在浏览器里输入 的时候,你向server发射的是``GET``炮弹,flask instance接受了你的弹,然后route到了index这个函数,好吧,激动人心的时刻到了:
#3. name = None 这个就是个赋值
#4. form = NameForm() 好吧,这个就是NameForm类的实例化,拿到一个form object。
#5.
if form.validate_on_submit(): 呵呵,这个嘛,意思是问一下#2中实例化的form
object,SB,你是在被人(1)submit(提交)并且(2)提交满足我的要求么?
好吧,前面说过了,我是在GET,而没有在submit(submit在HTML中为POST),好吧,我连(1)都不满足,所以也就没有#6、#7什么
事儿了。
#8 好的,app instance终于快要向你回馈了。给我把前面的from object和name变量一起带到index.html这个文件里吧。
哈哈,终于有jinja2的活儿了,@题主, 你丫也把index.html发上来呀 = =
index.html
里你写了个表单,里面有个叫做``name``的field和一个``submit``按钮,这些field和你的``NameForm``对应,好了,
对应填充的活儿和就交给jinja2吧,它会给你一个最终将在用户浏览器显示的index.html。
view的使命完成了,它成功的生成了数据。
app instance 拿到了view的数据,也该向client端发最终响应了。OK,server完成了这次request的response,用户拿到最终想要的东西了。
浏览器或者UA干的活儿我就不展开了,我的手已经抽筋了,
现在在用户的浏览器上,看到了index.html,上面有一个表单,那个表单上面有个文本框(有``What is your name?``的placeholder)和一个Submit提交按钮。
好
了,用户在那个文本框中写了一个名字,比如``John``,然后按了那个``Submit``按钮,这次提交回向server发射一个``POST``
请求,这个请求里面会带上文本框的名字(哈哈,就是name)和文本框name里面的值(yeah,就是``John``)。然后呢,到flask
instance中,request对象(如果不知道这是什么东西,看前文)里就会有所有这些有关请求的数据了。
辣么,辣么这跟from有毛线关系呢????
其实吧,form中的数据是flask从request(request是从environ构建的)中拿到并映射进form属性中的(映射过程发生在你实例化form的时候),这个过程我也不展开了。好吧,不知道有没有解释你
name = form.name.data
为什么会有数据的疑问。
我实在不想在打字了,好累噢!!!!!
好
吧,总结起来就是,HTTP utils将用户的raw request解析成符合wsgi规范的environ,然后flask
instance将environ丢到线程级的request
object里,在你实例化flask.ext.wtf.Form及其子类时,会从request object里解析并映射数据到form中。
关于读书的话,如果你觉得你实在看不明白,那可能是有关web底层一点的知识稍微欠缺,可以补补这块的知识,对于框架的处理机制,最好的办法是 看!!!源!!!!码!!!!!
看不懂就补基础,如此而已。
上面过程都是我信手打出来的,也好久没用flask了,写的时候也没查资料,如有bug或建议可以告诉我,以便我修改。