携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第3天，点击查看活动详情
拖拉拽从MFC、QT、winform、asp.net、dreamweaver交互显示相关的加速设计一直伴随着,其后因语言绑定性及交互设计更高的诉求,前端工程化等问题,逐步的失去活力,低代码作为最便宜实现的拖拉拽模式一直被津津乐道,这次主旨目的不是说低代码,说说"拖拉拽"这一模式及其应用
理解
我姑且把"拖拉拽"做一后续文中释义,从其应用性来说,多用于设计相关内容种,所见即所得同步设计过程和输出,
| 软件 | 用途 | 输出 |
|---|---|---|
| 界面设计软件 | 显示布局设计、交互、数据绑定 | 代码 |
| viso | 流程图设计软件 | 图 |
| PS | 图形处理 | 图 |
| 办公三件套 | 文档处理输出 | 文档 |
| etl | 定义数据汇总过程,定时执行策略 | 数据的抽取过程 |
其他如cad,视频裁剪软件等,以及后续的从单机搬运到web端的绝大部分软件和应用,如蓝湖、axure等都从其减量提速、易用性等方面入手进行的产品,这里不得不说魔兽系列的单机游戏"冰封王座"最成功之处就是其地图编辑器的加入,成就了澄海3c及dota,后续的东西都知道。 在此提炼一下关键,"拖拉拽"带有定义及工具属性,为了解决在既定的标准下实现个体多样性,输出可被解析的定义,最重要的设计理念就是所见即所得及工具化的易用交互设计。同时也包含了过程的测试验证。
应用
- 在线PPT及与此类似的如易企秀等H5显示交互设计,再如创可贴,axsure,蓝湖等
- 办公应用系列
- etl数据抽取,DBA工程师相对比较熟悉,如果你做过中台相关概念的应用或者架构,应该知道这种是程序处理种的一种典型,面对的是执行流程和过程。
此处针对软件系列应用,不得不提一个很基础,但很考应用市场的一个就是流程引擎,基本上绝大多数人都会涉及到此类开发,由此衍生出的表单配置及流程图定义两个点,基本涵盖了输出执行过程,及输出显示。
输出过程
以流程引擎种的流程图为例,包含有流程图的定义,同时也包含了流程实例的执行逻辑定义,定义好后,相关的审批会按照配置的逻辑执行,当流程审批规则变化时,调整流程定义即可,其本身包含了输出显示及规则引擎执行。再绝对一点儿讲,没办法前端一个人完成,必须得有服务端规则执行引擎的支撑。
输出显示
带有模板字串及图性质的,基本上对服务端依赖性和支撑要求并不是很强,或者前端能处理很大一部分工作,如低代码或是富文本编辑。
解决问题
当前我想要解决的问题是[业务编排]、[物联网规则引擎]、[流程编排]相关的定义工具,因其特性跟etl、流程图定义相类似,即输出过程(包含执行策略及输出显示), 将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。 这三项编排基本逻辑一致,但是针对的方向,及需要的节点配置偏重点都是不同的,如果考虑去实现,现有的领域内的实现,虽然有,分析其特点及相关开源内容调研,发现功能绝大多数属于半成品,且技术规范及实现方式无法有效改造熔炼,于是想到了自己去实现的成本及时间问题,考虑能否自己实现。
技术思路
成体系技术:
- Node-RED 是构建物联网应用程序的一个强大工具，其重点是简化代码块的“连接”以执行任务。它使用可视化编程方法，允许开发人员将预定义的代码块（称为“节点”，Node）连接起来执行任务。连接的节点，通常是输入节点、处理节点和输出节点的组合，当它们连接在一起时，构成一个“流”(Flows)。
技术选型采用的是node服务端,且前端技术栈以实现功能为目的,继承扩展性不强,强在其交互性做的比较好,整体性比较完善。
- bpmn.js bpmn.js是一个BPMN 2.0渲染工具包和web建模器。它是用JavaScript编写的，将BPMN 2.0 图表嵌入在浏览器中, 并独立于后端, 这也使得将其嵌入到任务Web应用程序中变得很容易: 可以独立使用也可以集成到你的应用中。
相对技术特点服务端有比较成熟的开源支持,深度及定制化程度比较高,不适合整体组件化扩展,在选型时需要注入服务端的纯净及改造型进行权衡。
- mxgraph 耳熟能详的processOn就是基于此二次开发而来(此处为mxgraph样例),交互的问题相对比较多,需要自己去优化,感官自定义改造工作量较大
- @antv/x6 相对来说其整理的应用场景支持的情况比较多,单纯的前端交互部分处理,相关文档思路比较清晰,初步选定以此作为前端部分的一个基础绘制层。
- 服务端部分
- 一种是将保存的数据结构化解析,通过节点树结构顺序及执行排序进行解析处理,根据不同的节点类型,执行相关的实现逻辑。
- 参考java bnpm纯服务端节点结构反射相关处理结合。
思路
- 区分流程执行策略,即节点执行顺序逻辑处理。
- 节点策略,不同的节点前后约束及配置属性,服务端处理。
- 类似于viso根据不同的业务场景,定制不同的节点及相关配置执行,以工厂模式进行设计。
- 前端部分设计会区分设计定义,预览,状态进度,调试执行动画等,以vue组件模式进行设计,有别于服务端,设计上保证公共显示部分的统一,内容的灵活自治。
实现时优先保证数据保存时的存储逻辑,因为其相对比较简单,再行处理服务端执行逻辑,增加相应的节点扩展及参数处理,此处贴上两个不同服务端处理的策略参考
杂话
线上配置两个源数据硬关联问题,在此处特别适用,详细做数据BI的老哥,如果有涉及到数据汇集,统计等问题时,进行数据预处理的时候要么在服务端处理,要么就进行指定的约定进行查询,此处是通过sql语法树进行实现的一些引导
结束语
牛身上取牛心，少不了庖丁解牛,选型参考调研过程中,并不是功能支持的越全面就应该去选某一个,越是全面的功能,重度的改造就越难改,要熟悉整套的数据流向及代码思路才能进行修改,分析相关的代码及功能的切合度及改造工期才能选出最合适的方案和执行。
目前仅仅是技术调研和计划实施策略的一部分,还有待demo及排坑,会在会序持续更新,打工人撸起来,每天挑战新东西。加油!!!!!!!
最后掏出你的一键三连吧!