表单设计器的设计与实现

在xxx信息管理这种业务场景中我认为最常见的操作就是对字段的处理(例如查询、编辑等区域的表单、图表的列名、表格的列名)，而字段恰恰是最为 '规范的'，它有自己的名称、类型

用对象或者说map这种结构而不用数组是为了可以精准对某个字段进行设置 而数组需要先遍历查找到这个字段再进行设置

可通过 formData 这个外部传入的对象来对数据进行统一的设置与读取

例如有的字段可以查询但不能编辑，我们可以引入一个场景的概念就可以轻易解决这个问题

名称既可以显示又可以编辑与查询而性别只能编辑与查询但不能显示，useScene是使用场景如果字段不支持这个场景那么字段不予显示(可自行实现禁用场景)

重点就在于m_canUse的实现，它用eval取巧的实现了一个场景逻辑字符串转布尔值的一个骚操作

看到这里可能有的朋友会很不解，为什么我要构造一个如此复杂的useScene,直接定义 canUpdate canQuery 这种布尔值变量来指定场景不就行了吗?

实际上需求是非常复杂多变的，场景可以说是无限的甚至是相互交织关联的、我们可能会根据用户的操作动态显示字段的显示隐藏，例如提交后显示提交人、提交时间等字段、撤销了就不予显示

我们可以在用户做某些操作时来动态设置sceneMap的状态来达到控制表单的显示、隐藏、禁用，当状态越复杂时你就越能感觉到它的威力

可以在动态表单内部监听表单的事件(可查阅相关UI库文档)、当表单事件触发时对外传递事件(携带当前操作的字段信息、$event信息或arguments)

有时我们想在任意两个字段之间插入一个非通用的ui组件，我们可以通过具名插槽来实现

这是一个动态表单的简易实现，需要大家结合自身的业务场景去填充各种各样的表单和相关的参数、事件

涉及到流程引擎的东西了吧

可以看下云海oa系统的流程表单设计