lbs@node
2018年的4月26日，我在自己的idea清单中，加上了一条“基于 nodejs 移植 lbs 博客系统”。
一、lbs 是什么东东？
它是一款比较小众的博客程序，是基于微软的ASP环境运行的，作者是SiC，最后的版本应该是 2.0.313，更新于 2007年7月3日。
(注：整理了一份代码到Git上，见：https://gitee.com/web3d/lbs )
二、扯淡
ASP在我那个年代，是学生能接触到的最好的编程语言和环境，尽管它不是语言，但一直作为一种编程语言的代称。ASP 基于IIS Web服务器，借助于微软Windows系统的脚本宿主环境，支持运行VBScript和JScript两种脚本语言，版本大致在5.X范围。
那时大家编写 ASP 程序都只知道用 VBScript。而 lbs 能够被大家所铭记，则是因为它是基于 JScript 写的。尽管其中有少量代码混合使用了 VBScript，但这不妨碍我等文艺青年的逼格追求。
熟悉我的童鞋都知道，我是有丝丝个人站长情节的。虽然没有经历第一代站长像雷布斯、小马哥、丁三石那个年代，但也算是经历过了草根站长的中后期阶段。
到后来所谓Web 2.0的时代，只剩下博客和博主了。再现在的新媒体时代，满眼则只剩网红了。
说这些呢，只是为了间接说明当年研究过各种“建站”系统，而自己也搭过不少次的博客站点。其中但凡需要动态程序支持的，都没有坚持下来；而翻译的一个静态技术文章的站点，反而因为其信息本质的价值得以一直存活。所以后来也放弃了自建，改用第三方服务，如博客园。
但情结就是情结，对一个事物有了情结，除非你真的得到拥有过Ta，否则，就不可能真的放下，对吧，小龙。
三、源头
这种情结驱使我在idea清单中添加了很多类似的事项，一大半都是已经打勾了的，因为很多想法自己虽然没去实现，但已经有人实现了，或者仔细考虑过实在没有意义。
而剩下的那些里面，基于 Node.js 改造这款 lbs 博客程序的意义在哪呢？
今年一直在用Nodejs，但主要是围绕遗留的系统，还是N年前ES5时代的回调、ES6时代的yield，混合写法的产物，代码的可读性比较差，这样的系统也不会闲着没事去完全重构，投入产出比在那。那么，就只有自己拿些东西练手了。
但程序员，你知道的，都是死脑筋，眼里只有技术，很少会有还具备比较完整的产品idea，能自产自销的。所以，不拿一个现有系统去折腾，而只是随便写点demo也是没用的，得不到完整的项目经验积累。
这样，就想起来了以前用过的这套比较小型的博客系统，刚好是基于Js语法写的，然后想看看基于Nodejs这样的代码该如何写。
四、过程
基本过程是这样：
1、五一之前的那几天，正式开始研究。
- 先解读了其代码组织结构，确定了基本的MVC方式的对应关系，比如lib、service、model、controller、view等；
- 数据库原本是基于Access的，在SQLite、MongoDB、MysQL中选，最后决定MySQL；
- 也做了框架选型，开始是想基于express/kraken 那一套，也让小部分功能界面跑起来了；也测试了国产的 thinkjs，基本在thinkjs下走了一遍流程，它是基于koa的，支持async/await了，代码可读性就能达到正常水平。
代码结构认知
1. 根目录下那些功能性代码文件如user.js 相当于是 每个功能的路由值 + 视图内容；
2. class 对应的是 Logic
3. source 对应是 控制器
4. lang 是语言包
5. data db 文件所在目录
6. www 所有前端静态资源文件
2、9月1号加深了不少认知
5月到8月实际上忙到非常，头发也快掉光。
8月底9月初那几天有了点空，又重新梳理了一下，定了一下基调。
基调：
1）小型；所以数据库继续使用 小型数据库如 sqlite；
2）路由；完全兼容 lbs 原来；含asp文件 及其它前端静态资源文件；
3）原来的代码结构尽量保持；
4）框架选型？实现一套兼容 asp 运行环境的库，达到最小化改动lbs 原有代码的目的；
5）模板引擎 ejs；js 原始语法
思考过程：
基于thinkjs，然后充分模拟原始运行环境
基于thinkjs是对的，其做了很多封装、整合的工作，避免了从头开始的过程；db层可以切换多种数据库引擎；
全局对象都应该以中间件形式存在，才能在相关代码中简单访问到 ctx 对象；
i18n 目前只能在控制器和视图中访问，如何处理？；
the 开头的一些全局对象
、lang、input、
Application、Sesson 函数
lang
func
connBlog
theCache
theUser
Session
Application
npmjs 中查找asp asp 兼容asp3语法、基于js-fpm、还没有完成，废的；node-fastcgi：与主流的nodejs 思路相背，坑会比较多，不考虑；
基于koa？
方法
先将标准降低一个档次；
以一种具体的框架的原有模式为主导，先实现一个lbs的版本；
然后再按最高标准：完全原封不动的在nodejs环境实现lbs的运行；而这种目标会因为涉及fastcgi、asp运营环境等属于服务器和框架级别的工作量，会导致无法达成目标；
9月13号
开始有空看看开源中国的新闻了，无意中看到eggjs的介绍，确定了基本这款框架来进行，主要的理由是，它这里面没有固定的Model概念，只有service，与lbs原来的代码结构能贴合一些。
Egg.js
『约定优于配置』
- 深度框架定制
- 高度可扩展的插件机制
- 内置多进程管理
- 基于 koa 开发，性能优异
11月16日
又是很忙的一个阶段，一下又到年底了，才开始将这个事放在手机的提醒app里每天提醒。
1、基于 egg.js 框架
2、代码保持原有的结构和写法；
3、2018 结束前完成；
4、确定开发任务清单
1）[x]框架确定-egg、[x]代码结构确定、[x]模版引擎确定-ejs、[x]数据库确定-mysql；
2）cookie、session
3）db 引擎 [x] 方法封装 []表名处理 [blog_] []top 条件处理
3）[x]i18n
4）view
5）cache []中涉及到原asp的 Application 数据存取、数组的 ubound 等专有属性方法；
6）user
7）lib
8）功能移植；login、register、user、default、article、comment、feed、trackback、stats、gbook；
从模版的迁移方式开始；
Helper 的实例还可以在模板中获取到
{{ helper.shtml(value) }}
'use strict';
module.exports = app => {
app.beforeStart(async () => {
app.locals = {
strTitle: 'Page Title',
};
});
};
[]func => helper
业务代码中 ctx.helper
视图中则 helper.
[x]lang []i18n
[]theCache
[]theUser
11月22日
将about页面视图基本调试正常，主要是解决了cache service；
下一步沿着登陆页面，走通theUser user service；涉及到 theCache、Session、connBlog、input、func、ServerVariables、Cookies、验证码
connBlog 是全局对象，意味着没有 context
theCache、theUser 应该是 请求级对象，都依赖于 ctx；
将Cache 一分为二；大部分属于 App级别的，少部分可以转到 helper中去；
12月17日
[x]1、验证码图片加载；
2、登陆结果处理；
3、注册
4、找回密码；
5、管理员登陆；
this.ctx.__('scode_invalid’)
不能展开成 __ 函数进行使用；
const { theCache, connBlog, session, helper: func, cookies, logger } = this.ctx;
最佳实践，可能可以尽量保留原代码；
用中间件的形式实现全局对象的数据初始化执行，让需要提前初始化的代码被执行；而且支持 async/await，否则无论是 application.js app.js 还是 context.js 都不满足场景；