Designer 总览
AuraBoot 内置了若干可视化 Designer,用于构建以元数据驱动的应用。它们并非彼此孤立的低代码孤岛。每个 Designer 都会生成结构化元数据,这些元数据可被 runtime 渲染、被 Plugin 打包、被治理检查校验,在导出后还可纳入 Git 评审。
OSS Designer 矩阵
| Designer | 路由 | 主要产出 | 典型负责人 |
|---|---|---|---|
| Page Designer | /page-designer | 列表、表单、详情和布局的页面 schema | 应用搭建者 |
| Dashboard Designer | /dashboard-designer | 含 widget 与数据源的 Dashboard 定义 | 分析师或管理员 |
| BPMN Designer | /bpmn-designer | 业务流程定义 | 流程负责人 |
| Flow Designer | /flow-designer | 通用图与 Workflow 结构 | 开发者或自动化搭建者 |
| Query Builder | /query-builder | 结构化查询定义 | 应用搭建者或分析师 |
| Report Designer | /report-designer | 可打印 / Report 页面定义 | 运营或财务用户 |
具体的菜单位置可能因部署与权限而异,但以上是应用路由中可见的核心 OSS 入口。
共享模式
大多数 Designer 采用相同的工作区形态:
- 左侧用于放置 Block、widget、节点、字段或查询元素的 palette
- 中央的画布或预览区
- 右侧用于配置所选项的属性面板
- 工具栏上的保存、预览、发布、导出或版本操作
- 可视化编辑器背后的类 JSON 元数据
这种一致性很重要,因为用户常常在多个 Designer 之间切换。一个 Model 可能在 Page Designer 中起步,继而供 Dashboard widget 使用,出现在 Report 中,并触发一个 BPMN Workflow。
元数据优先
Designer 应当用于创建平台元数据,而不是一次性的前端代码。例如:
- 列表页存储为页面 schema,而非自定义 React 表格
- Dashboard widget 绑定到命名查询或聚合源,而非手写组件
- Workflow 节点引用 Command、用户、角色或流程变量
- Report Block 引用 Model、命名查询或页面数据源
这让系统更易于迁移、测试,以及打包到 Plugin 中。
Designer 之间如何协同
典型的应用搭建流程如下:
- 定义 Model 与 Field
- 在 Page Designer 中构建列表与表单页
- 添加命名查询或聚合数据源
- 创建 Dashboard 以获得运营可见性
- 在 BPMN Designer 中建模审批或履约步骤
- 当用户需要导出或文档时,创建可打印 Report
- 使用 Aura Bot 和 agent 查询或执行同一份元数据
每一步都在保留平台单一事实来源(元数据)的前提下,叠加新的行为层。
版本与发布
Designer 通常会将草稿状态与已发布的 runtime 状态分开。具体行为因 Designer 而异,但工作模型如下:
| 状态 | 含义 |
|---|---|
| 草稿(Draft) | 可编辑的元数据,不一定上线 |
| 已保存(Saved) | 已持久化的进行中工作 |
| 已发布(Published) | runtime 可见版本 |
| 版本历史 | 之前保存或发布过的修订 |
在生产工作中,应将发布视为发版动作。在影响最终用户的变更发布前,先用真实数据进行预览。
选择合适的 Designer
| 需要 | 使用 |
|---|---|
| CRUD 列表、表单、详情与页面布局 | Page Designer |
| 指标、图表、KPI 与运营看板 | Dashboard Designer |
| 审批、路由、Service Task 与流程状态 | BPMN Designer |
| 可复用的图编辑器或自定义 Workflow 结构 | Flow Designer |
| 不直接编辑原始 SQL 的查询组装 | Query Builder |
| 可打印或面向导出的业务输出 | Report Designer |
凡是可以用元数据表达的功能,优先使用对应的 Designer。仅当行为确实超出平台元数据模型时,才使用自定义前端代码。
图片占位
网站图片清单包含每个 Designer 的截图。请在文档中插入图片前先补上真实的 OSS 截图,让用户看到实际产品形态而非通用的占位图。