编辑器和组件的定义
上篇文章把工具的定义以及工具和编辑器之间的关系讲清楚了,这篇文章主要讲编辑器和组件的定义。
编辑器的定义:
1 { 2 name:"PageEdit", 3 link:"http://xxx.xxx.com/edit/pageEdit", 4 helpDoc:{} 5 component:[{ //组件 6 7 }] 8 }
当然,还有一些属性没有全部写出来,比如:版本,需要的面板,面板的位置等
组件的定义:
1 { 2 name:"select", 3 alias:"选择器", 4 version:"1.0.1", 5 grpName:"interactive", 6 grpAlias:"交互组件", 7 attributes:[{}], //属性 8 events:[{}], //事件 9 methods:[{}] //方法 10 }
组件属性的定义:
1 { 2 name:"width", 3 alias:"宽度", 4 type:"number", 5 helpDoc:"", 6 setter:"numInput", //属性设置器 7 attributes:[], //当属性设置是复杂模式时,需要子属性描述 8 rules:[{ 9 type:"number", 10 min:"", 11 max:"", 12 minLength:"", 13 maxLength:"", 14 accuracy:"", //精度 15 require:"", 16 pattern:"", //正则表达式 17 message:"", 18 validatorFun:"" //自定义校验函数 19 }] //属性的规则校验 20 }
属性大概有以下几种类型:
String,Number,Boolean,Enum,Complex
这几种类型还有一些变种,举几个例子:
Boolean("展示","隐藏"),Enum("left:靠左","center:居中"),String[3],Number[*],Complex(String,Number),Complex(String,*),Complex(Number,String)[4]。
setter设置器是我们维护的一套组件列表,专门为组件设置属性用的,比如有:颜色设置器,日期设置器,选择设置器等
当类型为Complex时,需要定义这个属性的子attributes,举个例子:
多选框的选项是用户自己设置的,因此在定义时,需要这样子才能确定:
1 { 2 type:"Complex[*]", 3 attributes:[ 4 { 5 name:"Name", 6 alias:"名称", 7 type:"String", 8 setter:"", 9 }, 10 { 11 name:"LabelColor", 12 alias:"标签颜色", 13 type:"String", 14 setter:"" 15 } 16 ] 17 }
事件和方法的定义,参考面板的事件和方法的定义就可以了。
至于属性与属性之间的交互,也是通过定义实现的:
1 "properties": { 2 "source": [{ 3 "title": "width", //属性名 4 "reactions": [ 5 { 6 "when": "{{$self.value == '123'}}", 7 "target": "height", 8 "fulfill": { 9 "state": { 10 "visible": true 11 } 12 }, 13 "otherwise": { 14 "state": { 15 "visible": false 16 } 17 } 18 } 19 ] 20 }] 21 }
最后,通过加载器把编辑器的所有组件以及组件依赖的设置器的js加载回来,用户就可以通过拖拉拽的方式开始构建页面了。
这里还有一个需要深入讨论的点,构建的产物,也就是构建的json结构以及保存的逻辑是否需要统一定义,这里分两种情况,如果公司的编辑器是自主可控的,那就统一定义,为了后续工具的性能,增量更新,上一步,下一步等功能可以更好的实现;如果公司的编辑器会嵌入第三方的编辑器,人家不是改造json结构和保存的逻辑,那么就把它当做一个黑盒子就好了,我个人推荐是统一定义的,因为这为后续的性能优化提供了坚实的基础。
最终,保存到后端的是一份json文件,这份json文件可以在运行时框架里面跑起来,生成一个页面,供最终的用户去使用。
浙公网安备 33010602011771号