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或建议可以告诉我，以便我修改。
