项目中的列表页面已经能够正常读取销售订单数据，筛选栏、表格列、排序和导航也没有明显问题，可页面上方仍然缺少一个真正属于业务对象的标题。界面可以展示几十条订单记录，却没有清楚说明当前表格承载的是销售订单、销售订单项目，还是某种临时查询结果。这类问题看起来只是少了一段文本，实际牵涉到 SAP Fiori elements 的页面生成方式。传统的 SAPUI5 开发习惯，是在 XML View 或 JavaScript 控制器中直接给控件设置标题。SAP Fiori elements 采用的思路并不一样，页面结构主要由 OData 元数据和 UI 注解共同描述，前端框架读取这些信息后，再决定列表标题、对象页标题、字段排列、筛选条件以及操作按钮等界面内容。在这个机制中，表格标题不应该只是某个控件的临时属性，而应该成为业务实体元数据的一部分。对于销售订单实体来说，「Sales Orders」表达的是当前实体集合的业务含义。无论这个集合最终显示在 List Report、对象页子表，还是其他能够理解UI.HeaderInfo的消费端中，它所代表的业务概念都没有改变。SAP 官方将这种模式称为 metadata-driven UI。CDS 注解被保存在后端存储库中，客户端可以通过服务元数据读取这些描述，SAP Fiori elements 再依据注解生成相应界面。页面因此不再完全依赖手写的控件树，而是由数据模型、语义元数据和框架规则共同构成。围绕列表或表格标题，最直接的注解是下面这一项。@UI.headerInfo.typeNamePluralSAP 官方给出的代码形式如下。
项目中的列表页面已经能够正常读取销售订单数据，筛选栏、表格列、排序和导航也没有明显问题，可页面上方仍然缺少一个真正属于业务对象的标题。界面可以展示几十条订单记录，却没有清楚说明当前表格承载的是销售订单、销售订单项目，还是某种临时查询结果。这类问题看起来只是少了一段文本，实际牵涉到 SAP Fiori elements 的页面生成方式。传统的 SAPUI5 开发习惯，是在 XML View 或 JavaScript 控制器中直接给控件设置标题。SAP Fiori elements 采用的思路并不一样，页面结构主要由 OData 元数据和 UI 注解共同描述，前端框架读取这些信息后，再决定列表标题、对象页标题、字段排列、筛选条件以及操作按钮等界面内容。在这个机制中，表格标题不应该只是某个控件的临时属性，而应该成为业务实体元数据的一部分。对于销售订单实体来说，「Sales Orders」表达的是当前实体集合的业务含义。无论这个集合最终显示在 List Report、对象页子表，还是其他能够理解UI.HeaderInfo的消费端中，它所代表的业务概念都没有改变。SAP 官方将这种模式称为 metadata-driven UI。CDS 注解被保存在后端存储库中，客户端可以通过服务元数据读取这些描述，SAP Fiori elements 再依据注解生成相应界面。页面因此不再完全依赖手写的控件树，而是由数据模型、语义元数据和框架规则共同构成。围绕列表或表格标题，最直接的注解是下面这一项。@UI.headerInfo.typeNamePluralSAP 官方给出的代码形式如下。
