包含flasknosql的词条

Flask表单疑问，这个name是怎么传进来的

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

python web框架对比

flask本身相当于一个内核，几乎其他所有的功能都要用到扩展：邮件扩展Flask-Mail，用户认证Flask-Login，数据库Flask-SQLAIchemy等，都需要用第三方扩展来实现。flask没有默认使用的数据库，可以根据自己的选择MySQL或者nosql。其WSGI工具箱采用Werkzeug的路由模块，模板引擎则使用jinjia2。这两个也是flask框架的核心。

常用扩展

框架对比：

总结：至于选什么框架-轻重对比-框架选择上：

flask：后期业务升级迭代，更换技术方案，自由，灵活，高度定制。

Django：快速实现业务，不考虑技术选型，越简单直接越好。

Tornado：tornado走的是少而精的方向，注重的是性能优越，它最突出的是异步非阻塞的设计方式：HTTP服务器，异步编程，websockets。

Django和Flask这两个框架在设计上各方面有什么优缺点

（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 是一种具有平缓学习曲线和庞大社区支持的微框架，利用它可以构建大规模的web应用。是搭建社区平台的神器之一。 利用它可以构建大规模的web应用。学习上手Flask非常轻松，但要深入理解却并不容易。本书从一个简单的Flask应用开始，通过解决若干实战中的问题，对一系列进阶的话题进行了探讨。书中使用MVC（模型-视图-控制器）架构对示例应用进行了转化重构，以演示如何正确地组织应用代码结构。有了可扩展性强的应用结构之后，接下来的章节使用Flask扩展为应用提供了额外的功能，包括用户登录和注册、NoSQL查询、REST API、一套后台管理界面，以及其他特性。然后，你会学到如何使用单元测试，保障代码持续按照正确的方式工作，避免极具风险的猜测式编程。 一个简单的Flask 项目入手，由浅入深地探讨了一系列实战问题，包括如何使用SQLAlchemy 和Jinja 等工具进行Web 开发；如何正确地设计扩展性强的Flask 应用架构和搭建MVC 环境；对于各种NoSQL 数据库的特性，何时应该、何时不应该及如何使用它们；通过使用Flask 扩展快速实现用户的身份系统、RESTful API、NoSQL查询、后台管理等功能；如何创建自己的扩展；使用Celery 编写异步任务，使用pytest 进行单元测试等；最后介绍了如何部署上线，包括使用自己搭建的服务器或使用各种云服务，以及如何权衡和选择这些不同的解决方案。

Flask-Cache 怎么缓存动态内容

InternetExplorer（包含傲游，世界之窗等和IE使用同一内核的浏览器） 工具-Internet 选项-浏览历史记录一栏点“设置”-查看文件

浏览器自动打开了IE的缓存文件夹（临时文件夹）。