![](https://csdnimg.cn/release/download_crawler_static/86298541/bg3.jpg)
程,与触发时机。
4、 结构化的全局配置对象。通用的逻辑,抽象成全局配置对象,
在所有功能点生效;全局配置对象只起到一个默认值的作用,不
强制。开发人员可以在个性化的界面中订制配置。
5、 分级过程化的补丁。框架中提供了几种级别的补丁文件。对
于一些需要逻辑过程的项目组个性需求,要提供一些可以编写这
些代码的地方,这些代码可能会覆盖一些框架逻辑,可能会提供
一些全局逻辑;一些不具备添加到产品框架功能的个性需求,或
者一些需要紧急响应的过渡性需求响应,也可以在这种补丁文件
中添加。这种补丁文件只能由项目组架构师来修改,或者产品部
定向发送給指定项目组。
前段框架的补丁
目前,
CRM
产 品 的 前 端 框 架 中 , 包 含 几 个 这 样 的 补 丁 文 件 :
Crm-Ext-Extends-1.000-v1.0.js
、
Crm-Ext-Patch-1.000-v1.0.css
用于与底层支持库
EXT
框架的一些逻辑修改、
BUG
修复、以及底层功能、浏览器版本适配等,它的加载
时机是
Ext
加载之后,
WLJ
框架加载之前;
systemPatch.js
用于
WLJ
框架相关的一
些逻辑覆盖等,它的加载时机是
WLJ
框架代码加 载之后,框架构建之前;
defaultPatches.js
用于为业务逻辑代码添加一些通用默认逻辑,不强制覆盖,它的
加载时机是框架构建之后,业务代码加载之前。
另外,还有一些小的规范,如:6、功能性需求由框架来做,业务
代码只负责需求描述,质量高、风险小;7、句柄接口的订制,顺序的
安排,尽量与需求文档的格式靠近;8、补丁、更新等,尽量以文件为
单元进行设计编写;9、提供一些框架外的实用功能,如日志 API,日
志控件等;10、配置信息不急于持久化,不急于存到数据库。
代码文档化的尝试
关于第七点,是代码文档化方面的一点尝试。
Crockford
先生最早提出代码文
档化的观点。他说大家写代码,变量名要取好,方法名要取好,注释要写好,要
让别人能看懂。可惜的是,这只是一种提倡。
python
做的好点,但也仅仅在代码
排版上有些进步,而且,它自身也陷入了无限回调的泥潭,所做有限。
WLJ
的开
发框架中,最初的一些接口设计有些参考了咱们需求文档的写法。比如,先编写
输入输出字段,然后增删改面板逐个描述;字段约束逐条编写;业务限制也是附
在最后逐条编写。我总觉得,代码文档化这种大命题,可以在具体的业务框架中,
通过框架的强制性,是能够有一些前进的。
框架的设计,就是取舍;最难的也是取舍。说多了,就成哲学了。
绍雷说,抓住痛点。痛点与前瞻相结合,就是取舍的准则。
i. 面向架构师的全局配置
框架提供一个全局化的配置文件,该文件中定义了各类全局性的配
置属性。一些无关于业务的默认值、开关定义在这里。同时,包含了界
面上各级别右键菜单逻辑的定义,以及可扩展的前端数据类型配置。这