2018年2月9日
从开始到最后大概写了一个月左右(中间有半个月要上考研班)。
基本上从头踩坑踩到尾
前端方面用了materialize、vue、jQuery
其中materialize更多是样式,对着文档搞没什么问题
之所以混用jQuery和vue是因为有些页面没必要用vue,但是又有一些小地方需要动态控制。
因此个别页面用到了jQuery
比如被我用来当作标签的

<div class="chip" v-bind:class="tag[4]">
	<img v-bind:src="tag[3]" onerror='$(this).attr("style","display:none")' onload='$(this).attr("style","")' />
	<span v-text='tag[0]'></span>
</div>

这里由于不确定图片是否有效,采用这种js判断的方式来保证看上去不那么难看(其实不是必须要到jQuery)

vue方面遇到的主要的坑就是,它的绑定(v-model)是异步的,可以理解成虽然他是双向绑定,但是其实是有一个延迟的。大部分情况下其实没有什么问题。但是如果我在js里修改变量值,然后立即提交表单,表单里的值其实还是没有变化的。因此需要一个回调函数来确保同步之后再继续下面的步骤。这里的Materialize.updateTextFields();则是materialize里的更新表单动画的函数

vue.$nextTick(function() {
	Materialize.updateTextFields();
	vue.loading = false;
});

后端方面遇到坑比较多,不过大部分还是在写一些很没意思、重复性的工作。
前期架构没有想太透彻就开始着手去做,导致后面有大量的返工。
按照构想,主要分成3层:路由层、前端、后端。其中数据库则在后端的底层。
后端从数据库拿到需要的数据,处理完输出到/api/xxxx,然后前端通过fetch来获取需要的数据。然后屈服于seo优化,页面部分就直接用jinjia渲染了,只在那些涉及到搜索的页面使用了这个思路。

花费了大量时间在上下文上。
一般flask里常用的上下文是g,session,cookie
其中,session是加密的cookie。
g存在于单个请求。从before_request到after_request都是它的生存周期,但是这个请求结束后,他就被销毁掉了。也就是说,同一个用户,开两个网页时对应的两个g是相互独立的。
而session(cookie)则是存在用户电脑上的(貌似别的框架里,session在服务器,用户存的是session_id)。这也就是说,我们可以用session来判断用户身份,毕竟http没法记录用户状态。但是session和cookie是有大小限制的,因此有很多想法其实是没法实现的。
比如我曾经想在所有的before_request记录用户访问的url,然后存到session或者cookie里,用于去重的访客统计,然后就超出空间大小了……

至于一些写法上的问题,前期没有注意,导致函数名不是很规范,同时一开始为了清晰,把get和set功能分开放在两个文件夹,然而这在后面调用的时候更麻烦。
对于同一个内容,合在一起其实更方面,他们他们有大量的相互嵌套调用。

另外,数据库方面使用sqlite3。为了方便别的地方调用,把常用的select、insert、update、delete抽象出来,把所需的参数按照字典的形式传过去,然后拼接成语句。

搜索方面使用了jieba分词,先把整篇文章分成词语,然后统计词频,鉴于这个过程很慢,统计完后直接存在数据库里。

markdown转义参考了segmentfault的markdown转义。
不过看了一半就自己瞎写了
整体还是能跑起来的,嵌套以及一些不规范的语法也都能正确转义,但是在一些奇怪的地方可能会有bug。
目前还在测试中。
最大的体会,大概是:不要想着修bug,不影响用就行了,先上线再慢慢修吧。反正永远也修不完……