Wnd Frontend插件

没有看错,我居然还在写这个插件。从WndWP更名为Wnd Frontend,从一开始手写表单到后面采用表单生成类,从一开始能跑起来,到现在全面oop编程,模块化编程。

六月份宣布上线几个网站后,插件的功能就已经全部实现了。后面三个多月的开发,从插件的实现思路上没有本质上的变化,变化的是具体的代码实现。

其中最重要的改变主要是从函数编程转为OOP编程(面向对象):

  • 多重筛选OOP重构
  • 支付、充值实现OOP重构
  • 手机、邮箱验证OOP重构
  • 站内文章表格列表(posts table) OOP重构
  • 将核心逻辑分层为MVC模式,整体结构更加清晰易懂
  • 以类的方式封装:单个操作界面及对应的控制处理
  • 除部分常规函数外,全面采用命名空间及自动加载的方式,实现惰性加载
  • 完善用户中心,邮箱绑定,手机绑定,及找回密码等账户相关操作
  • 安全性上:默认禁用了xmlrpc、WordPress默认的api
  • 其他细节优化

oop改造主要在于实现低耦合高内聚,便于后期维护。这些话读起来实在是空洞。我之前也不是很理解。但经过实际地oop重构,我感受最明显的是,oop的思维的确能让人编程从更高更全面的角度去思考问题。比如当我定义一个类时,我首先想到的是,这个类需要从外部接收那些信息,处理完成后,如何传递结果。这能够让你先从接口的思路去想问题,而不是一上来就是各种细节处理的问题。因为细节总是可能变,而接口通常稳定得多。一旦想清楚了接口的问题,后面即便是细节变动,也不至于影响到全局。

除此之外,例如用户交互界面,从代码的角度看,完全可以用一个函数实现。这一块我使用oop重构的主要原因不是维护上的考虑,毕竟输出一个HTML能有多复杂的逻辑呢,而是处于惰性加载的考虑。如果采用函数式编程,在每一个请求产生时,我们都要去加载编译所有的函数,而实际应用中,用户的操作通常是单一的,或者是一个接着一个的,不是每个请求都需要加载编译所有的函数。如果采用oop将每个界面封装为一个类,那么在绝大部分情况下,这些类都是不用加载,或者只加载很少部分,只有在当前操作需要的时候再自动加载。

同理,交互界面背后接收并处理数据的控制层,当采用oop之后,也实现了只在用户发起了对应操作的时候再加载对应的类文件。

以上都是oop一些众所周知的优点,你可以这样用,也可以不这样用,只是相对来讲更好一些。在Wnd Frontend中,oop重构产生了实质功能提升的是多重筛选这个类。在oop改造之前,我采用的是一系列函数来组合实现的,外部采用了一个封装函数,这个封装函数必须要传入大量参数才能实现多重筛选的定制。而且过程繁琐。采用oop重构后,整个筛选构造过程大大简化,而且轻松实现了之前苦思冥想也没能实现的高度定制化。同时还实现了ajax筛选。多重筛选是Wnd Frontend中非常核心的一个功能,也正是七月份尝试采用oop重构多重筛选成功后,才有后面的一系列改进。

整体而言,目前这个插件已经成为了我自己的一套前端开发标准,基于这个插件,开发绝大部分交互网站,都变得更加轻松,基本上只需要根据业务需要生成几个表单,添加对应的操作权限控制即可。

截至2019.10.08,插件基本以定型下来。后面再修改基本也是细节优化层。前前后后耗费一年时间,15000行代码,近千次修改,还有视力损伤的代价,个中艰辛,不足为外人道也。

 

留下评论

电子邮件地址不会被公开。 必填项已用*标注