Sailing - 设计器中的元数据组织

Sailing

概述

Sailing的目标之一就是屏蔽技术细节, 提供高层(业务层)的思维方式和操作界面.
设计器也应该以此为目标之一.

以下按照重要性列出了设计器中需要实现的特性
- 按模块组织
- 为主要场景设定默认值, 提供最小配置模式
- 按主要场景来设计操作流程, 减少入口. (但还是需要为"高级模式"保留所有可能的入口)
- 对内容较多的元数据, 按用途调整布局.
- 为QSS提供语法高亮和Intellisence
- 为UI提供拖放操作

按模块组织

目前设计器中元数据是按照元数据种类来组织的, 这种方式一方面太过技术化, 另一方面增加了操作的复杂性.
例如: 在明细单主表中增加了一个数量合计字段, 此时需要:
1. 打开UI列表, 找到UI, 添加数量合计字段的显示.
2. 打开实体计算列表, 找到实体计算, 添加计算规则.
3. 打开XXX列表, 找到XXX, XXX

如果按照模块组织. 那么场景是这样的.
1. 展开明细单模块, 展开明细单这个单据, 打开明细单这个单据类型
2. 修改UI
3. 修改实体规则
4. 修改XXX
这样的交互就比较流程, 不会让人摸不着头脑

强关联弱复用的元数据, 操作内嵌

例如目前主要的验证器, 初始化器, UI, Process的复用等, 基本上都是在单据, 单据转换, 单据跟踪等地方独立使用的, 复用的需要不高, 那么最好能够在创建单据, 单据类型, 单据转换, 单据跟踪时, 直接内嵌编辑以上内容, 操作体验上拟合这是两种元数据的裂痕.
由于应用中确实存在单独使用以上元数据的情况, 所以在非主要层次中保留可以访问模块下所有元数据的入口.

示例

菜单组织方式

• 销售
  
  • 实体
    
    • 销售#销售订单(有内容)
    • 销售#销售报价单(有内容)
  • 单据
    
    • 销售#销售订单(有内容)
      
      • 销售#出口销售订单(有内容)
        
        • 相关单据转换
          
          • 销售#明细单读取销售(有内容)
          • XXXX#XXXXXX(有内容)
        • 相关单据跟踪
          
          • XXXX#XXXXXX(有内容)
          • XXXX#XXXXXX(有内容)
      • 销售#进口销售(有内容)
        
        • ...
  • 预警项
  • 协作
  • 报表
  • 资源
  • 基础代码
  • 其他设置 (以下为通过其他元数据引用, 自身很很少直接使用的元数据)
    
    • 编码生成
    • 初始化器
    • 验证器
    • 工作流
    • 数据导入
    • 动态查询
    • process
    • 业务场景
• 采购
• 出运
• ...

内容布局

紧凑紧凑再紧凑. 对UI等需要控制最终展现方式的元数据, 尽量做到所见即所得; 对其他元数据, 能用列表的用列表, 项目是在太多的, 才考虑块.

单据

• 基本信息
  
  • name: 名称
  • aliasName: 别名, 用于菜单和详情显示
  • icon: 图标
  • seq: 顺序, 用户菜单大模块排序
  • enableVersioned: 开启版本化
  • entity: 关联实体
  • mainOrgType: 主业务组织类型
• 单据类型共享信息(以下配置由该单据项下所有类型共享)
  
  • validator: 通用验证器
  • defaultListActions: 默认列表页动作
  • defaultDetailActions: 默认详情页动作
• 单据通用列表
  
  • genBillTypeMenu: 生成单据类型菜单. 开启后, 余下配置禁用
  • sourceFilter: 列表数据过滤
  • listItems: 列表项
  • listSummaryItems: 列表统计
    
    • enabled
    • name
    • aliasName
    • seq
    • icon
    • uiScript
    • views
    -
• 附加列表
  
  • additionalListViews

单据类型