2020-07
22

jinja模板,你好

By xrspook @ 19:20:33 归类于: 烂日记

我终于做到了用模板的方式以及我自己的数据生成静态网页。暂时我还不知道,那些放进去就能用的格式类东西应该怎么在生成网站的时候顺便一并放进去。肯定是有方法的。虽然现在我手动挪一挪也无所谓。我觉得那大概是一个获取文件,然后解压到目标位置的操作。

jinja的模板套用比我想象中简单。在进行我自己的操作之前,我复制了网上的一个教程的代码,发现真的很容易。模板本身也可以通过浏览器查看效果,这个非常棒。从前BSP不就是干这种事吗?无论是可视化编辑的,还是纯代码操作的,其实都是在设计模板。现在我也终于明白,为什么相比于其它核心功能,在模板方面,我为什么总感觉自己有那么多的经验,因为实际上,我的确在那个方面花了很多时间。现在我已经不记得BlogBus的模板是怎样的了,唯一的印象是他们用的是代码编辑。他们会给你一些核心代码的封装,你可以把那些东西放在指定的某些模板里。封装的东西以外的部分,你可以通过css,或者js去控制,但是封装在里面的,基本上就是一个无药可救的状态了。所以有些格式你觉得你应该可以控制得了,实际上你却做不到,因为封装在里面,已经把格式给写死了。不知道如果我在css那里强行加个important,能不能扭转局面,但显然,当时我根本不知道有important这种东西。css的important的确威力无穷,但是important如果经常用,就会破坏规则,也不好维护。不得已我才会用,即便用了,一个css文件里面,通常不会超过三处。

以前的模板设计,我只是能处理一些格式上的东西。现在,我自己写脚本生成静态网站。无论前台后台,我都玩了,我得顾及前台的模板形式。也要考虑后台的数据整合以及数据的架构类型。在用jinja模板之前,我用的是人肉低端的字符串合并。虽然实际上,我做的低端操作也是实现模板的功能,但就维护来说,这实在太困难了!如果一个网页里面有很多数据是动态的,我就不得不把网页切分为很多份。切着切着,我都不知道自己切到哪里了。就数据生成效率来说。我的低端做法效率会更高,至于为什么,我不知道。9498个页面,我的低端做法转化需要22秒,jinja模板只需要32秒。这个不是偶然事件,在进行9498个页面转化之前,我先进行了一个只有几个页面的测试。结果跟大数据的很类似,低端做法,要比高端做法快1/3。这其中的原因是什么呢?据说jinja已经是个生成速度自称为“快速”的脚本,如果是另外一些,可能更慢。9000多个页面才多10秒钟,任何人都忍受得了。就维护的便捷性来说,低端拼接的维护成本随便超过10秒,所以用jinja模板绝对是值得的。这让我想起了我最在行的邮件合并,用word和Excel联合起来批量生产东西。我不知道其他人玩这个能溜到什么程度,反正这个东西一直都是让我引以为傲的,当然了,这种技能,也是后天逼出来的,工作使然也。

一些我觉得可能挺不容易的东西,居然很轻松就被我攻克了,感觉非常意外。接下来,生成搜索引擎所需的索引,估计不是件容易的事。生成索引,最重要的是思路,而过程不过是一些机械操作而已,我必须掌握好那个思路!

2020-07
21

改进

By xrspook @ 9:18:56 归类于: 烂日记

当我把电子书的列表从800多KB改成几个以后,整个静态网站的生成速度就从之前的120秒降为20多秒。20多秒的生成速度跟生成markdown文件没什么区别了。准确来说,生成速度更快了,因为少了一个markdown转换的过程,我猜可能是这样吧。虽然我已经绕了一个大圈又重新做了一个判断,如果我直接从点点转换成静态网站,而不是先格式化为wordpress标准的XML格式,估计速度会更快,但可以肯定的是,如果那样的话,我还是得做不少的判断,因为点点的文件里面不同类型的核心内容是不一样的。其实最简单的方法,是我生成wordpress格式文件的时候把分类继续放在分类,不把博客的名字放在分类,不把分类作为其中一个标签,相对来说这样的改动是最简单的。其实现在我绕了一个圈再回去,也没麻烦多少,因为那个标签是第1个,而我的判断是,如果找到了某个标签,就马上停止循环,所以虽然每篇日志的标签有n个,但判断第1个以后就结束了。就循环来说,没耗多少时间,只是代码会显得又长又臭。

近段时间我一直在纠结如何把手动输入的字典搞得好看些。除了好看,也要容易维护。最明白的方式当然是自己写键值对,但是那么多的引号,那么多的冒号,那么多的逗号,想想都觉得好疯狂。最整齐最不容易出错的方式是一行一个,但那样的话,好像有点奢侈了。所以有时我也搞不懂自己,到底是想节省空间,还是维护容易。

昨天晚上,我纠结一个问题,如果某个单词被我用作变量,在字典里那个单词又是一个key,同时这个单词也是个文本。有没有某个函数能把某个变量只当作是某个名字的字符串呢?如果这样,我的某句话就可以写得很简洁。否则的话,当我调用函数的时候,我就要把这个单词写一遍,当作字符串再写一遍。或者你会说,我直接把这个变量等于这个字符串不就好了吗?显然,我之所以把那个单词当作变量,肯定是因为其内涵跟字符串不一样。所以我试试是不是自己挖了个坑给自己跳呢?我明明不应该把这两个东西命名成一样。

有些时候我会问一些很弱智的问题,明明我是知道的,但是一下子就是想不起来。归根到底,我觉得是我的基础还不够扎实。在完成了静态博客的部署以后。我还没想好我是继续把Think Python那本书从我中断的地方继续看下去,还是应该从头开始,复习一遍,加深印象,因为那些很基础的东西在用着用着的时候,我觉得自己已经忘光了。所以到用的时候,我又得翻箱倒柜。那些东西,我明明应该已经掌握的。

现在的静态网站转换,我是用很低端的字符串连接整出来的。有些字符串是一成不变的,有些字符串是变量。我就在变量的之前之后把静态字符串断开,储存在某个文件里。最后就像穿珠子一样,把动态和静态的东西连在一起,最终合成一个网页。实际上,这是一种模板的思路。接下来,我要利用python的模板引擎,把静态的东西写在模板里,把动态的东西放在某些参数中。这才是我的网页转化应有的方式,但我不确定,这样的转化效率会不会比我现在的低端做法还要低。对我来说,那是一个未知的世界,我非常想,立马通过实践得出答案。

人在求知的路上会越发明白到自己的无知。

2020-03
16

背景颜色

By xrspook @ 11:58:14 归类于: 烂日记

又花了一个下午的时间,我总算把超链接给搞定了。之前我就已经发现了那么个现象,如果我为一个图片做超链接,而那个超连接的默认的格式有悬停背景色的时候,无论我怎么整,图片下方都会有一条线,问题只是,那条线是粗还是细。昨天我遇到的问题是我需要在三个64*64像素的小图片上面做超链接。三个的图片完全没有文字,让人很绝望的无论我如何操作,那三个图片下面都有一个64*17的超链接方块,从颜色看来,那就是我在那个区域设定的超链接背景颜色。无论我怎么设置,分辨出来的东西还是会有那个颜色。之所以会是17,是因为我把文字的高度设定为16px。最终我终于记起了一条规定,如果之前你没有对某个元素设定规则的话,后面你可以重新为这个元素设定格式,但有些如果前面你已经设定了格式,后面,你又要推翻这个格式,并把它变成无格式的话,这是不可能的,除非我祭出大招“!important”。我在某片区域对超连接设定了背景颜色。但是在某些特定的情况之下,我又要把背景颜色去掉,单纯的background-color:transparent做不到的,但假如暴力的“!important”就可以。要去掉那个背景颜色,在不加“!important”的前提下,我把超链接的颜色设置为和那片区域背景颜色一致,所以颜色虽然存在,但就不会被看到了,但这么低端的做法CSS维护的时候就麻烦了。这个让我纠结了一个下午的事从前我也就结果,但因为太久远,已经忘记了。

昨天我匆匆把翻新过的COLOR3模板上线,感觉还不错。其实我也没改什么,主要是一些功能完善以及格式上的东西。我还专门找了一个色卡的网站去研究到底背景要用什么颜色。最普通的是浅灰色,但是那实在太普通了,然后我把黄色,橙色,粉色,蓝色,绿色,这几种很浅的马卡龙颜色都试了一遍,感觉有点怪怪的。说不准到底是为什么,反正就是和主体区域的白色混搭起来会有点刺眼。另外一个让我纠结的就是版头的颜色,之前我用的是纯黄色和纯橙色。这两个颜色加起来会让人有酸酸甜甜的热烈感觉,但是跟那些浅色混在一起,会莫名地让人觉得刺眼。以前模板的背景颜色是白色,同样也是橙色和黄色之所以没感觉刺眼,是因为我在所有板块外面都加了5px的边框,而这一次我把5px的边框全部都去掉了。之所以要去掉边框,是因为某一次,不知道谁留言说,我那些黑色的边框让人觉得辣眼睛。看到那条评论的时候,我马上实验在网页上实时修改掉那些边框,但只是单纯去掉边框,就像PS掉大熊猫的黑眼圈一样,怪怪的。当我对版头和背景颜色一筹莫展的时候,我顺手写了个纯黑色背景上去,出乎我意料,效果非常好,简直是让人有惊艳的感觉!外围黑色让核心部分的内容更加突出提神。因为高对比度,5px的黑色边框根本不需要存在。除了黑色以外,我也在网站上实时测试了其他颜色,发现用深色效果都挺好,所以我可以根据心情,随便换颜色。比如喜庆的时候换个纯红色。几乎可以这么说,只要是偏深的颜色都适合当我的背景颜色,因为主体区域我用的是鲜艳的颜色。

我不是一个美工,我总喜欢把东西弄得很整齐而已。真正的美工大概都很在乎意境,所以我永远都到达不了他们的境界。

2020-03
15

搞清楚comments.php

By xrspook @ 11:28:25 归类于: 烂日记

时间用在查找代码上去得特别快。感觉问题还没解决,时间就已经溜了。大体上看,就只有几个大问题需要解决,但实际上那些东西是完全没有头绪应该怎么去做的。昨天我花了一个下午的时间去处理comments.php。那个模板用来设定在哪里显示评论,哪里显示评论框,这其中还不包括评论框里的具体格式。看上去这是非常简单的事情,实际上,还是要考虑好几个问题,但显然,10年前,做那个模板的时候,我没有在comments.php这个问题上纠结,我顶多是往里面放了一些我设定好的CSS,所以那个部分的逻辑到底是怎样的,我没去修改,沿用的是某个模板。实际上我用的那个模板是不是标准的,我也说不准,因为我实在不记得当年我用作改造的模板是哪一个。因为通常WordPress的官方模板都非常简单,甚至可以说简单过头,于是你不知道该如何在那个的基础之上改造。大概之前,我的那个comments.php测试的时候,我只是考虑了一般情况。但除了正常情况,WordPress里还是会有一些极端情况,比如说某篇日志被设计为密码可见。无论是日志还是评论,在输入密码之前都应该是一片空白。那个模板就很神奇,日志部分已经是提示输入密码才可见,评论部分直接不显示就行了,但实际上,那里居然在会提示一次输入密码才可见,显然这就是画蛇添足了。让我纠结的时间最长的是嵌套格式的代码。因为正文部分我分为左边和右边,左边是文章的主体以及评论框,右边是边栏。这两个板块,一个是float向左,一个向右,一旦代码嵌套不合理,右边的边栏就会进入左边,又或者直接消失,也有可能是因为缺少结束嵌入代码,所以网页底部的东西飞上去了。要解决这些结构格式上的问题,就首先要搞清楚,那些php代码的开始结束位置。比如说某篇文章设定了不允许评论,但是对于已经有的评论,你还是要把它们显示出来,然后在最后一条的那里显示不许再评论。之前我根本没有测试过不许评论这个功能,显然当我在撰写日志的时候设定了不允许评论以后,之前的模板相应网页会出状况。而之所以这样,是因为默认的模板里面我只在if下面添加了足够多的格式结束标签,在else里面没写。不许评论就是else的部分,判定函数应该是评论是否开放,但实际上,不允许评论这句话从结构看来,应该是放在评论列表的最后。这样的风格才会统一,因为有些时候,不许评论之前可能文章已经有评论了,如果硬生生地把那放在允许评论就有评论框,不允许评论评论框消失并写着不允许评论,那样就太生硬了。

我花了几乎一个下午的时间去处comments.php,最后终于搞清了里面的逻辑关系。为了让那些if跟else,以及endif能更好地维护,我在上面做了很多注解,基本上每个的那里我都会写清楚了对应的是哪个,同时我也进行了缩进。那么以后找的时候就不会那么头痛。如果写代码的人用的是大括号,显然就不需要纠结endif对应谁。我也不知道为什么那个人不用大括号,在没有标注也没有缩进的情况下搞清那些东西真的好费神。

纠结不是毫无用处的,这会让我变得更强大。

2020-03
13

减法

By xrspook @ 8:47:49 归类于: 烂日记

插件能解决的问题,为什么要自己写代码呢?东拼西凑代码就能解决的问题,为什么还要把那加到小工具里呢?我也不知道我为什么要这么纠结,以前我从来没有这么纠结过,但是那是以前。回看10年前自己做的WordPress模板,从现在的角度去考虑,其实很多地方我已经冥思苦想了,因为至今要我给出一个更好的解决方案,尚且无能。当时,我之所以把这个模板叫做COLOR3。因为英语的THREE和FREE的发音比较类似,完全翻译成中文就是色彩飞扬,因为我在模板里面加入了好多颜色,几乎可以说是五颜六色。我用了很多颜色,但是我几乎没用图片。整个模板里我只用了三张小图。为了找到那三张适合的图,我寻觅了不少图库。在那个时候我的这种做法是比较大胆的,因为基本上主流好看的模板都需要有不少小型图片支持,之所以是小型,是因为即便只是小小的一块图片也可以通过横向纵向重复的方式扩展成无限大小的大图案。从好看的角度考虑,背景用一大张高像素的图当然厉害,但是大图的体积也非常大。如果遇到网速不好,又或者服务器糟糕的话,非常有可能路人已经看完了你的网站,你的背景图片都还没加载出来。在我设计COLOR3的时候,我非常注重网站的加载速度,因为我的blog的服务器放在国外,所以从中国访问速度肯定会有点慢。也正是因为我在模板里几乎没有加入图片,所以我不需要考虑把网站的图片放哪里这种问题。不过我为网站设定了一个ico。那个东西极小,但是一旦被收藏,可以有很高的识别度。设计模板的时候我没加图片,因为我觉得真正吸引读者目光的应该是文章本身。可能是文章的文字,可能是文章的配图。从前好长一段时间,每篇文章我都几乎会配图,但是后来,配图这种事对我来说变成极小概率事件。从2014年夏天开始到2020年,在这超过15年里,我每天都写至少一篇。5400多篇日志,想想都觉得很疯狂。对别人来说,基本上数不出什么当年今日的日志有多少,但我可以数出一大堆。所以很多人blog里版块的链接有随机文章,相关文章,最近文章,热评文章之类的东西,但是对我来说,一个当年今日已经足够震撼了。刚好当年今日这个功能,其实根本没必要用插件去实现,简单的语句就可以做到。在10年前,我做COLOR3的时候,我就把插件的语句直接放到了模板的function里面。但是,那只是把php引用的代码具体的模板里,是定死的。那种自由远不如把当年今日做成一个小工具。小工具意味着可以对不同功能的东西进行区块管理。几乎可以这么说,有无限排列组合的可能。对低端人士来说,你有多少个箱子、有多少个工具,你就只能对那些进行排列组合,但是,对高端人士来说,无论是小工具还是放小工具的箱子,都是想有多少,就有多少的。之前,我只会创造箱子,但昨天,我连小工具都有点懂得该如何模仿组装了。

10年前,我通过插件让blog在文章链接上面开了挂。10年后,我选择的是要开挂,自己来,能节省,就绝不开挂。

© 2004 - 2021 我的天 | Theme by xrspook | Power by WordPress