我的天

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

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联合起来批量生产东西。我不知道其他人玩这个能溜到什么程度，反正这个东西一直都是让我引以为傲的，当然了，这种技能，也是后天逼出来的，工作使然也。

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