无限长的归档页面

其实这个问题由来已久，我曾在7月25日给 pi#bitcron.com 发邮件询问归档页面加载文章的限制。当时我嫌分页不够直接，于是写了 limit=999，却只在归档页面上看到大约300篇文章，然而我的博文总数高达800+篇。我猜是因为速度等原因限制了全部加载，并求教了不使用分页情况下加载全部文章的方法，第二天便得到了回复。

可以手工传入 page 这个参数，就可以取得后面一页了的数据了。
不是 323 篇， 是 300 篇， 系统做了限制，每次最多获取 300 条，一来避免对系统产生性能问题，二来可以避免页面本身的性能问题了。
已经做了调整，将最大数目改为 1000 篇。
但是，建议在当前情况下，不要在 Dashboard 的 Cache 策略设定为 No 之类的，对页面的实际生成速度会影响比较显著。 :)

当时我对 Hepo 所说的 page 参数一无所知，心想着既然已经改成了1000篇，应该还够我用好几个月，便没做他想。直到后来设计主题「它布」的时候，机缘巧合下用到了自动加载功能，这才第一次接触了 page 参数。

作用：对内部产生的内容，可以实现滚动自动翻页载入。

接受参数：<as_ul=False, callback=''>，如果 as_ul = True，则最外部的 DOM 元素是 ul，反之则是 div；callback 是一个字符串类型，表示一个 JavaScript 的函数名，为翻页载入成功后的回调函数。

代码示例:
 

+posts.set_min_per_page(6)
+page(as_ul=True)
        for post in posts: li.post

        span.date= post.date('%Y-%m-%d %H:%M')
        .content.markdown= post.content

但真正将它跟归档页面结合起来还是前几天的事。制作定制主题的时候，客户提出“归档页不需要翻页，滚轮就是最好的翻页”，只是因为要求简单，不需要按照年份分组，我便没有使用自定义变量空间，而是直接用了官方的 posts 变量空间，所以也没有遇到什么难题。

今天因为纠结自定义变量空间下的 category 问题，读了好几遍官方文档都不得其解，想起曾经也问过很多相关问题，说不定以前看不懂的答案，现在会有所启发。于是我开始倒叙查看过去的问题邮件，看到了 page 参数，觉得好像在官方文档里读到过，便又去翻找。这才发现，原来 page 参数说的就是自动加载功能，感到很多混乱的思考连成了一条线。

说干就干，经过几轮测试，我终于弄懂了其中的逻辑，技术小白的心酸。官方给出的示例代码里有一句设定每页最少显示篇数的代码 +posts.set_min_per_page(6)，刚开始我以为用这个就行，便去掉了自定义变量空间里的 limit，结果发现行不通。加了 limit 以后才发现上述代码压根没用，才意识到这是 posts 变量空间的参数，在自定义变量空间下当然不能使用。

那么 limit 设置成什么数字比较好呢？想想每年的博文应该不会超过366篇，就这么敲定了。亲测效果很棒，虽然跟 toggle 有些冲突，但影响不大，也无法避免，就 let it be 了。以下是 archive.jade 中的代码片段，做个记录。

entries = d.get_data(types='post', limit='366', sort='desc').group('-date:year')
+page(as_ul=false)
    for year, year_posts in entries
        header
            h2= year
            year_start_date = '%s-1-1' %year
            year_end_date = '%s-1-1' %(year.int+1)
            yearly_count = d.get_data(types='post', return_count=true, date_start=year_start_date, date_end=year_end_date)
            span= yearly_count

        ul: for post in year_posts: li
            time(datetime= post.date.format('%Y-%m-%d'))= post.date.format('%m.%d')
            a(href=post.url)= post.title

如果之前官方设定的300篇是专业人士认定的理想值的话，那么现在打开归档页面的首次加载值（366篇）已经表现得非常好了。不论如何，是大大优于1000篇的，也让博文越写越多的我从今往后高枕无忧了。

2017.08.24更新：在 Fooleap 的提示下，我重新思考了这个冲突，发现确实不可解。因为自动加载实现的是同样格式的项目不停加载，而我的归档页面除了文章还有年份标题，要么只加载文章没有年份标题，要么年份标题重复了。所以最后我还是移除了这项功能。在文章不多的情况下，把归档和分类分别统合在一个页面内是我觉得最理想的方式，非常符合我对于简洁的追求。然而文章数量一旦多起来，又开始令人苦恼了。交给未来的水八口解决吧。