虽然可视化视图编辑器几乎成了国内低代码平台的必备要素，但在to B的大型复杂项目中的列表视图，可视化视图编辑器无论是交互体验还是配置效率不如预期。
并不是可视化视图编辑器的设计或决策有问题，低代码平台在不确定面向场景的时候，可拖拽的编辑器总是一个保守而正确的决定。
但如果如果面向场景确定，完全不需要可拖拽的编辑器。在Salesforce中，从对象建模到配置视图，整个过程没有任何拖拽操作。
salesforce的对象配置：
视图配置：
视图效果
截图来源：salesforce
面向复杂场景的列表视图配置设计
salesforce的设计是非常精准的: 复杂场景确定对象字段和关系是最基础的工作，对象确定后，列表视图可以根据对象的字段/关系进行渲染，这就是以元数据对象驱动视图，视图生来就具备对应元数据对象的所有增删改查功能。
如果用可视化的视图编辑器，一个对象数百个字段，各自设置可见性、表单控件，并且配置增删改查按钮功能和数据，难度极大，效率极低。
虽然元数据驱动型低代码视图配置效率高，支持场景复杂，但也有一个基本问题——模型无法完全描述视图：
在salesforce中，对象的列表视图布局，在对象管理中设置。
但在实践中，视图需求和模型设计总是基于不同的角度考虑。模型设计考虑的是数据存储查询，视图考虑的是具体业务场景的展示。
如果视图的所有表现、功能逻辑都通过模型本身的特点来描述，那视图毫无扩展能力：同一个对象可能有多个不同的列表视图，字段可见性、查询条件设置都应该以具体需求场景为准，这些完全超出了模型的描述
因此针对列表视图单独的配置页是有必要的。
在我司实践中，配置流程上完全借鉴salesforce，只是多了多环境部署。但在视图上，我们提供了很多配置能力。
主流程图
列表视图配置功能
列表视图基于对象渲染，对象字段类型决定渲染方式和编辑控件，因此配置上也是基于对象字段，而非视图本身进行扩展。
字段级设置
字段级设置可以改动字段的展示名称、展示格式等，该配置在列表和表单中全局生效，如果不同功能单元有不同的展示要求，则在对应的功能单元中修改。
分单元细节配置
在不同的单元，会有该单元的特殊视图配置。
-
表格列
可设置列宽、固定列、渲染控件、样式等
-
查询项
可更改默认查询控件、设置查询操作符、查询默认条件、常驻查询条件等
-
表单项
可更改默认编辑控件、设置校验规则、只读等
表格功能性设置
主要有分页、勾选、表格工具（行高/全屏/字段排序等）、表头搜索、底栏汇总、整体样式等
表单功能设置
主要有表单布局、分组、折叠等
扩展场景
-
api及拦截器
该功能是视图与元数据对象解耦的关键，可以通过更改视图绑定的元数据对象增删改查接口，使其能够访问外部服务。
-
按钮和工作流
借助工作流消化各种业务逻辑
-
其他杂项
主要是一些全局性的设置：全局变量、全局事件、日志等
相关UI参考
实践中的问题
相比可视化编辑器，这套方案的主要问题是，运行时效果与配置界面难以对应。
比如用户想要在表单里新增几个字段，按照一般低代码平台的套路，应该是找到对应的表单，再设置表单的字段。但这套设计里，是找到这些字段，开启可修改。
再比如想要开启扩展子表格功能，很多人不知道去哪里设置。一方面从视图上很难想到对象之间的对一对多关系，另一方面名字定义的不标准，也会使用户难以将扩展子表的效果与配置时的明细子表联系。
另外还有一个问题是：难以将部分视图组件与对象联系起来。
比如下拉搜索控件来自于对一对象，明细表格来自对多对象，如果在建模时不会考虑关系，那么视图就无法配置对应的控件。
再比如，字符串类型的字段，无法使用时间范围选择器。这个设计符合逻辑，但并不符合现实：甲方给到的数据就是字符串时间戳。建模时字段类型考虑的是它实际格式，很难会去联想这个字段类型对应的控件。
这些些问题并不是配置时无法实时预览造成的，背后的根本原因是，这套方案基于对象进行配置，而可视化编辑器基于页面本身进行配置，所以后者更符合直觉。
从表单编辑器建模
上述问题有一个解决方案：通过表单编辑器建模——这也是明道云的做法。
表单建模的优势是，屏蔽了对象关系各种概念。用户关心的是视图效果，这里有一个下拉搜索，那里嵌入一个明细表格，虽然背后是对一、对多关联关系，但这些底层逻辑并不会暴露出来。
当然明道云的设计，只适用于简单场景：表单——列表——元数据对象完全耦合，单独针对其中某块进行调整很难。如果一个对象的不同场景有不同的字段展示需求，就完全没法满足。不过这种思路还是值得借鉴的。
