blog posts的提交
让我们从简单的开始。首页上必须有一张用户提交新的post的表单。
首先我们定义一个单域表单对象（fileapp/forms.py）：
class postform(form):
post = textfield(‘post’, validators = [required()])
下面，我们把这个表单添加到template中(fileapp/templates/index.html)：
{% extends “base.html” %}
{% block content %}
hi, {{g.user.nickname}}!
{{form.hidden_tag()}}
say something:
{{ form.post(size = 30, maxlength = 140) }}
{% for error in form.errors.post %}
[{{error}}]
{% endfor %}
{% for post in posts %}
{{post.author.nickname}} says: {{post.body}}
{% endfor %}
{% endblock %}
到目前为止没啥新的东西，你可以看到，我们仅仅添加了另一表单，就像我们上一次做的那样。
最后，功能试图把所有东西都联系在一起，并被扩展来处理这个表单（fileapp/views.py）:
from forms import loginform, editform, postform
from models import user, role_user, role_admin, post
@app.route(‘/’, methods = [‘get’, ‘post’])
@app.route(‘/index’, methods = [‘get’, ‘post’])
@login_required
def index():
form = postform()
if form.validate_on_submit():
post = post(body = form.post.data, timestamp = datetime.utcnow(), author = g.user)
db.session.add(post)
db.session.commit()
flash(‘your post is now live!’)
return redirect(url_for(‘index’))
posts = [
{
‘author’: { ‘nickname’: ‘john’ },
‘body’: ‘beautiful day in portland!’
},
{
‘author’: { ‘nickname’: ‘susan’ },
‘body’: ‘the avengers movie was so cool!’
}
]
return render_template(‘index.html’,
title = ‘home’,
form = form,
posts = posts)
下面让我们逐一回顾一下这个功能中的变动：
我们导入了post和postform类
我们接收了来自两个路径下的index和视图的post请求，因为那就是我们如何接收提交的请求。
当我们通过表单提交到功能视图后，我们会把新的post记录录入数据库。然后就像之前做的一样，通过常规的get请求来访问它。
templat会收到一条额外的内容–表单，所以它会提交给文本域。
在我们继续之前还有最后一点提醒：注意下面我们如何添加一条新的post请求到数据库中：
return redirect(url_for(‘index’))
我们可以很容易的跳过重定向，并且允许它跳到模板渲染部分，而且效率更高。因为所做的所有重定向在经过web浏览器之后，都返回到这个相同的功能视图中来。
所以，为什么选择重定向？考虑到当用户写下一个blog post请求之后，它只需提交然后点击浏览器刷新按钮。“refresh”命令能做什么呢？浏览器会重新发送最后发布的请求作为一个“refresh”命令的结果。（译者注：由于个人水平有限，如果您发现译处与原文有出入敬请指正。谢谢！）
如果没有重定向，那么最后提交给表单的就是post请求，所以一个“refresh action”会重新提交那个表单，将会导致第二次提交的post记录和第一次写入数据库中的是相同的。这样的行为not so good.
若是有了重定向，我们可以强制浏览器在表单提交之后发出另一个请求，它抓取了重定向的页面。这是一个简单的“get”请求，所以“refresh”动作会重复“get”请求而不是再次提交表单。
这个简单的小技巧避免用户在提交一个blog post请求之后，不小心刷新页面导致重复写入post请求。
展现blog post请求
下面我们来说点有意思的东西。我们要从数据库中抓取blog post请求并失之显示。
如果你回忆一下之前部分文章，我们曾创建了许多所谓“虚假的”的请求并且在首页上面显示了很长时间。这些“虚假的”对象是作为python list在索引视图中创建的。
posts = [
{
‘author’: { ‘nickname’: ‘john’ },
‘body’: ‘beautiful day in portland!’
},
{
‘author’: { ‘nickname’: ‘susan’ },
‘body’: ‘the avengers movie was so cool!’
}
]
但是在上一篇文章中，我们创建的查询语句允许我们从“关注的人”当中获取所有的请求，所以我们可以用下面的这个语句来替换上文（fileapp/views.py）:
posts = g.user.followed_posts().all()
然后当你运行这个应用的时候，你将会看到冲数据库中抓取到的bolg post请求。
user类的followed_posts方法返回了一条抓取我们感兴趣请求的sql查询语句。在这个查询语句中，callingall()检索所有的请求到一个list当中，所以我们以这个很像我们一直沿用至今的“虚假”请求的结构结束。他们如此的相像甚至template都没有注意到。
此时您可以在此应用上自由发挥。你可以创建多个用户，让他们follow其他人，然后发布一些信息来看每一个用户是如何看到它的bolg post请求数据流的。
分页
我们的程序是越来越像样了，但是我们面临另外一个问题。我们在首页显示了所有的followed post。如果一个用户有上千篇followed post将会发生什么情况？或者一百万篇？就像我们可以想象到的，抓取并处理这么庞大的对象列表是十分低效率的。
我们可以显示把这么大量的post分组来显示，或者分页。
flask-sqlalchemy可以很好的支持分页。例如，我们可以通过如下方法，轻松获取某个用户的前3篇的followed posts：
posts = g.user.followed_posts().paginate(1, 3, false).items
分页方法可以被任何query对象调用。它接受3个参数：
页码，从1开始
每页显示的记录数
错误标记。如果是true,如果接收到超出记录范围的页面请求，那么404错误请求将会自动反馈到客户端浏览器。如果是false，那么一个空列表将会被返回，而不显示错误。
paginate的返回值是一个pagination对象。这个对象里面的成员包括了请求页面中的记录列表。稍后，我们会探讨pagination对象中另外一些有用的东西。
现在让我们来想想，如何在我们的view函数中实现分页。我们可以先把一些配置信息添加到我们的应用中，包括我们每页需要显示多少条记录（fileconfig.py）:
# pagination
posts_per_page = 3
使用全局配置文件去改变我们应用是一个很好的构思，因为我们只需要去一个地方就可以修改所有的配置。
在最后的应用中，我们当然会使用比3更大的数字，但是作为测试，使用小的数字会更有效。
之后，让我们来看看urls是如何判断请求不同的页面的。我们之前已知道，flask的routes可以接受参数的，所以我们可以在url添加后缀，来指明我们想要的页面：
http://localhost:5000/ >{% endif %}
结束语
以下我把本文开发的带分页的微型博客应用代码打包并提供大家下载：
下载：microblog-0.9.zip.