lbs@node(lbs asp blog 移植到 nodejs)

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 都不满足场景;

五、仓库地址

https://gitee.com/web3d/node-lbs

posted @ 2018-12-28 15:15 x3d 阅读(...) 评论(...) 编辑 收藏