Elpis：从Json Schema 到 页面

1. 概括

这个架构的核心是：不直接开发一张业务页面，而是先用 Schema 描述页面；系统再把这份描述解析为统一的页面模型，最后由通用渲染器生成真实界面并连接业务数据。

因此，页面能力从"写死在 Vue 代码里"转移为"由配置声明"，开发重点也从重复搭建表单、查询栏和表格，转向定义业务字段、展示规则和交互行为。

业务意图
  │  商品要展示什么、能按什么查询、可执行哪些操作
  ▼
Schema 配置
  │  机器可理解的页面描述
  ▼
解析层
  │  校验、拆分、转换、补全默认规则
  ▼
页面模型（View Model）
  │  搜索模型 / 表格模型 / 表单模型 / 操作模型
  ▼
通用渲染器
  │  选择控件、组织布局、绑定数据与事件
  ▼
可交互的业务页面

2. 三个核心角色

2.1 配置：页面的声明式契约

Schema 是页面的"蓝图"，描述的是结果，而不是实现步骤。它通常包含：

配置内容	表达的业务含义
字段	页面有哪些业务数据，例如商品名称、价格、创建时间。
类型	字段是文本、数字、日期、枚举还是对象。
展示规则	字段是否展示为表格列，列标题、宽度、格式化方式等。
搜索规则	字段是否可查询，以及使用输入框、下拉框或日期范围等控件。
操作规则	页面和每一行可执行哪些动作，以及动作需要哪些参数。
数据规则	页面从哪里读取数据、如何提交数据、如何理解接口响应。
...(可扩展)

例如，同一个 product_name 字段可以同时声明为"表格中的商品名称列"和"搜索栏中的动态下拉选择器"。字段只定义一次，却在不同视图中复用。

{
  product_name: {
    type: 'string',
    label: '商品名称',
    tableOption: { width: 200 },
    searchOption: {
      comType: 'dynamicSelect',
      api: '/api/proj/product_enum/list'
    }
  }
}

这就是声明式配置的关键：业务方表达"商品名称应该如何被使用"，而不必编写"创建一个下拉框、请求选项、创建一列"的具体 UI 代码。

2.2 解析：从通用描述到可运行的页面模型

原始 Schema 面向配置者，需要足够完整；但不同页面区域只关心其中一部分信息。解析层的作用类似一个轻量的编译器：将通用、静态的配置转换为渲染器可以直接消费的运行时模型。

以当前系统为例，解析器会依据字段是否带有 tableOption 或 searchOption，将一份源 Schema 投影为两个模型：

源 Schema
  │
  ├─ 带 tableOption 的字段 ──► 表格 Schema
  │                             列、列标题、宽度、格式化规则
  │
  └─ 带 searchOption 的字段 ─► 搜索 Schema
                                控件类型、默认值、选项来源

解析层承担四类职责：

1. 筛选：只把某个区域需要的字段交给该区域，例如表格不需要知道下拉选项。
2. 转换 ：将 tableOption、searchOption 等领域配置转换为统一的 option，让渲染器以一致方式消费。
3. 补全：结合默认值、URL 参数、当前项目或用户上下文，补齐运行时需要的数据。
4. 约束：未来可在此校验未知控件类型、错误字段、非法接口和不完整按钮参数，将问题提前到配置阶段发现。

解析的价值在于隔离变化。配置格式可以持续演进，组件库也可以替换或升级；只要解析输出的页面模型保持稳定，渲染器不必跟着每一次配置变动而重写。

2.3 渲染：用通用能力生成真实界面

渲染层不直接理解"商品管理"或"客户管理"这样的业务概念，它只理解统一的页面模型：

• 搜索模型中的 input 渲染为输入框；select 渲染为固定选项下拉框；dynamicSelect 则先加载远端选项。
• 表格模型中的每个字段渲染为一列，并将列配置传给底层 UI 组件。
• 操作模型中的按钮渲染为页面操作或行操作，再根据事件键分发到删除、打开表单或业务自定义逻辑。

渲染器是"解释执行"的一层：同一套组件面对不同 Schema，就能生成不同的页面。增加一个字段、改变列宽、将输入框改成下拉框，通常意味着修改配置，而不是复制或重写页面。

3. 从配置到页面的数据闭环

页面生成不是一次性的静态过程，而是一个持续响应用户操作的数据闭环。

Schema 配置
   │
   ▼
解析为搜索、表格、操作等页面模型
   │
   ▼
渲染搜索栏和数据列表
   │
   ├─ 用户输入查询条件
   │       │
   │       ▼
   │   搜索控件统一产出字段值
   │       │
   │       ▼
   │   转为接口查询参数，刷新数据列表
   │
   └─ 用户触发操作
           │
           ▼
       从当前行和操作配置构造参数
           │
           ▼
       调用业务接口，成功后更新页面数据

这个闭环中，Schema 既定义了静态的页面结构，也定义了动态的数据边界：

• 搜索控件将用户输入规范化为业务参数；
• 表格将接口数据映射为字段展示；
• 操作按钮从当前行提取必要参数；
• 接口结果回流，驱动页面重新渲染。

所以 Schema 不只是 UI 配置，更是前端视图与后端业务服务之间的一份契约。

4. 模板继承：复用与差异并存

图片中"模板页"和多个项目配置体现的是另一项关键能力：将共性沉淀为模板，将差异留给项目覆写。

一个行业模板可以提供通用的菜单、商品字段和标准操作；不同项目只声明自己特有的名称、首页、菜单项或字段差异。系统在使用前将两者按业务键合并，得到一份完整的项目页面配置。

行业 / 产品模板              项目差异配置
（共用页面结构与能力）       （品牌、菜单、字段覆写）
           │                       │
           └────── 合并 ───────────┘
                       │
                       ▼
                项目专属 Schema
                       │
                       ▼
              解析并渲染为项目页面

它解决了两个看似矛盾的需求：既不为每个项目复制一份后台系统，也不要求所有项目完全一致。模板负责稳定性和一致性，项目配置负责灵活性和个性化。

5. 架构边界：什么适合配置，什么应保留代码

配置驱动并不意味着所有事情都必须配置化。它最适合结构稳定、重复度高、规则明确的场景，例如检索页、表格页、标准表单和常规 CRUD 操作。

对于复杂的可视化、特殊流程、强交互编辑器、跨页面协同或高度定制的权限逻辑，仍应保留自定义页面和业务代码。

更适合 Schema	更适合自定义代码
字段展示、筛选、分页、标准表单	复杂拖拽、图形编辑、实时协作
固定数据接口的查询和提交	高度动态的业务流程和状态机
通用操作与字段级权限	特殊算法、复杂联动、深度定制交互
多项目复用的后台页面	具有独特产品体验的核心页面

通过 schema、iframe、custom 等页面类型并存，平台可以在标准化与自由度之间保持平衡：高频页面走配置化路径，非标准页面保留代码实现。

6. 总结

配置 → 解析 → 渲染，本质是一条将业务意图转化为用户界面的生产线：

1. 配置负责声明页面应具备的业务能力；
2. 解析负责把声明编译成稳定、可消费的页面模型；
3. 渲染负责复用通用组件，将页面模型和真实数据变成可交互界面。

它的最终目标不是"少写几个页面"，而是将重复的后台页面开发沉淀为平台能力，让页面从一次性代码资产变为可复用、可组合、可治理的业务配置资产。