关于sap:SAP-产品-UI-里的容器组件的概念和开发概述

4次阅读

共计 5023 个字符，预计需要花费 13 分钟才能阅读完成。

这是 Jerry 2021 年的第 68 篇文章，也是汪子熙公众号总共第 345 篇原创文章。

Jerry 之前的文章，谈谈 SAP 产品 UI 开发中的组件概念，已经提到，无论基于何等开发技术的 SAP 产品 UI，其出现在最终用户背后的视觉效果，都是通过若干逻辑意义上的组件 (Component) 实现的。这些逻辑意义上的组件，代表了 SAP 产品提供给最终用户交互性能的细粒度的封装，比方查问订单的界面，和创立订单的界面，开发时通常搁置于两个不同的组件内实现。

这些 UI 组件通常都蕴含模型层，视图层和控制器层，通过开源或者 SAP 自研的 UI 框架彼此交互，协同工作。

不少 SAP 产品的 UI 开发，组件的定义和边界十分清晰，比方 SAP UI5 里的 Component.js, SAP ABAP Webdynpro 和 WebClient UI 的 Component，SAP Commerce Cloud Accelerator UI 里的 JSP Component 和 Spartacus UI 里的 Angular Component. 这些产品的 UI 开发工作，次要就是进行这些 Component 的代码编写。

下图所示的 SAP Cloud for Customer UI Designer 里这些类型各异的 UI 模型，如 OWL，QAF, FS 等等，更是典型的 UI 组件的例子。

另外一些晚期的 SAP 产品，比方运行在 SAPGUI 里的 SAP ERP，其界面采纳 ABAP Dynpro 实现，后者没有明确提出 UI 组件的概念。但 ABAP Dynpro Screen 和 PAI/PBO 逻辑组合在一起，从设计和性能角度来说，也造成了一个逻辑意义上的 UI 组件。

本文通过一系列 SAP 产品 UI 为例，介绍 SAP 产品 UI 开发畛域里另一种重要的组件类型，我称其为容器组件。

同前文形容的蕴含了具体界面和业务性能的 UI 组件相比，容器组件本身并不存在出现给最终用户的界面，而是单纯地充当容器的角色，它们是包容其余 UI 组件的组件。局部容器组件可能反对一些简略的管制逻辑编写，运行时可能依据开发人员指定的条件，动静地决定应该显示其蕴含的哪些 UI 组件。

上面通过 Jerry 参加过的一些 SAP 产品 UI 开发工作中的具体例子，来介绍 SAP UI 容器组件的概念和作用。

下图是基于 SAP WebClient UI 开发的 SAP CRM 产品明细页面。红色区域代表一个个一般的 UI 组件，绿色区域是一个容器组件，后者决定运行时，到底应该显示其包容的哪些 UI 组件。

启动事物码 BSP_WD_CMPWB, 关上 UI 组件开发环境，查看 ID 为 PRD01OV 的产品明细页面的容器组件。下图是该容器组件包容的 UI 组件列表。运行时产品明细页面显示的理论内容，是这个列表的子集。

SAP Cloud for Customer 同 SAP CRM 一样，都借助了工作核心 (Work Center) 和工作核心视图 (Work Center View) 的概念来实现权限管控。用户只能看到调配给其的工作核心视图蕴含的具体界面。对开发人员来说，SAP CRM 的工作核心只是配置表里的一些条目，而 SAP Cloud for Customer 里的工作核心和工作核心视图，成为开发工具里能实实在在看到和编辑的 UI 模型。一个工作核心蕴含若干个工作核心视图，下图是一个例子：

点开上图所示的 Sales Order 工作核心视图，能够看到该工作核心视图蕴含了一个 OWL Component：

OWL 是 Object Work List 的缩写，即下图所示的给最终用户提供搜寻界面的 UI 组件。这体现了 SAP 产品对于 Transaction 解决的一贯思路：客户个别都是从 SAP 产品 UI 提供的事务数据搜寻页面开始，从搜寻后果里选中一条，浏览明细页面。SAP Cloud for Customer 和 SAP Business ByDesign 的搜寻页面，就是由类型为 OWL 的 UI 组件实现的，而这些 OWL 组件，又被搁置到工作核心视图这个容器组件内。

SAP Cloud for Customer 还存在另一类应用宽泛，功能强大的容器组件 EC Component，即 Embedded Component，嵌入式组件。EC Component 作为容器控件，自身可能包容其余的 UI 组件，同时其自身可能以紧耦合和松耦合的形式，嵌入到另一个父组件中，通过多种形式使其外部包容的 UI Component 同嵌入的父组件之间进行数据传递和通信。

借助 SAP C4C 的 Mashup 技术，EC Component 无论是在 SAP C4C 规范开发，还是合作伙伴二次开发畛域，都有着宽泛的用处。比方下图所示 SAP C4C 的地图集胜利能：

以及我之前的文章如何在 SAP Cloud for Customer 页面嵌入自定义 UI 介绍的场景，比方咱们能够把第三方网站或者自开发的部署在 SAP BTP 平台上的页面，通过 EC Component 嵌入到 SAP C4C 规范 UI 下来。

作为基于无头电商 (Headless Commerce) 架构解决方案的代表之一，SAP Commerce Cloud Spartacus UI 页面的展现，采取纯 CMS 驱动的思路来实现。

CMS(Content Management System)管理员，在 SAP Commerce Cloud Backoffice 里定义电商云前台须要显示的页面内容。这些页面内容定义，通过裸露成 OCC(Omni Commerce Connect) API 的形式，提供给 SAP Spartacus UI 生产。后者拿到须要显示的页面内容之后，负责具体的视觉效果 (Visual Effect) 渲染。

以 SAP 电商云的主页 homepage 为例，CMS 管理员在 homepage 里，保护该页面包容的 Content Slots(内容插槽)。一个页面能够包容多个内容插槽，每个页面插槽对应屏幕一个区域。

这些内容插槽，依照显示内容，把 homepage 划分成若干个区域，比方 HeaderSlot,FooterSlot,SiteLogoSlot, Section1Slot,Section2Slot 等等。

每个内容插槽里可能搁置一到多个 CMS Component，这里的 CMS Component 起的是占位符的作用—— CMS 管理员不关怀每个 CMS Component 具体显示的视觉效果，甚至不关怀这些 CMS Component，到底是由 JSP 还是用 Angular 来实现。

下图展现的是 Section1Slot 这个内容插槽，搁置的两个 CMS Component 的名称。SAP 电商云 Accelerator UI 和 Spartacus UI，会别离应用 JSP Component 和 Angular Component 技术实现这些 CMS Component. 大家能够把下图 Backoffice 所示的搁置在内容插槽中的 CMS Component，与其和在 Accelerator UI 和 Spartacus UI 中的 Component 之间的关系，类比成面向对象编程中接口和其具体实现类的关系。

上图形容的 Section1Slot 内容插槽和名为 Electronics Homepage Splash Banner Component 的 CMS Component 的蕴含关系，可能在如下的 OCC API 调用后果中反映进去：

Spartacus 解析上图 API 响应后果，拿到 name 属性为 Electronics Homepage Splash Banner Component 的组件，得悉其 typeCode 为 SimpleResponsiveBannerComponent，而后在其保护的映射表里，查找到该 CMS Component 对应的 Angular Component 名称为 BannerComponent，于是就会渲染 BannerComponent 对应的模板文件。

下图是 SAP 电商云 Spartacus 页面的 homepage 渲染结束的界面，其中黄色高亮区域就是内容插槽 Section1Slot 的起始地位，而两片绿色高亮区域，别离就是该内容插槽里搁置的两个 CMS Component，对应到 Spartacus UI 里通过 Angular Component 模式渲染的起始地位。

尽管从最终用户的视角登程，发觉不到容器组件的存在，但对于 Spartacus UI 的规范开发人员和须要进行二次开发的合作伙伴来说，Spartacus UI 的容器组件是一个比拟重要的概念。

SAP Spartacus UI 的入口页面，实现代码位于 storefront.component.html 模板文件。不到 30 行的代码，把这个基于 Angular 的 UI 界面，划分成了 header,main 和 footer 三大区域。

在运行时，客户拜访任何 Spartacus UI，咱们都将会将渲染出的 HTML 原生代码对应的 DOM 元素，搁置在上图第 21 行 Angular 路由指令 router-outlet 的正下方，成为其兄弟节点。

以客户拜访 homepage 的场景为例，最初生成的 HTML 源代码如下：

上图是了解 SAP 电商云 Spartacus UI 运行时渲染原理的关键所在，展现了 SAP Spartacus 两个重要的容器组件。

标注 2 显示的 cx-page-layout, 以及其若干个子节点 cx-page-slot, 别离对应了 SAP Spartacus 两大容器组件 PageLayoutComponent 和 PageSlotComponent 的选择器。

从 PageLayoutComponent 容器组件的模板文件实现可能看出，每个 PageLayoutComponent 的实例，理论就是 CMS 管理员在 Backoffice 里保护的一个 Page 在 Angular 端的具体出现模式。

当最终用户拜访 SAP 电商云 Spartacus UI 时，后者调用 OCC API，将对应 Page 在 Backoffice CMS 中的模型数据取回来，该 Page 调配的内容插槽信息，存储在上图第 16 行的 slots$ 变量里。PageLayoutComponent 应用 Angular 结构型指令 *ngFor, 遍历这个 slots$ 变量，将每条内容插槽记录的数据，传递给另一个容器组件 PageSlotComponent，其选择器为第 15 行所示的 cx-page-slot.

PageSlotComponent 依据 PageLayoutComponent 传入的内容插槽信息，解析出该插槽调配的 CMS Components 信息。因为单个内容插槽能够调配多个 CMS Components，因而在第 10 行同样应用结构型指令 *ngFor, 遍历该内容插槽须要显示的每一个 CMS 组件信息，将该信息传递给第 19 行咱们团队自定义的 Angular 指令 cxComponentWrapper.

这个带有咱们部门名称前缀 cx – Customer Experience 的自定义指令，会依据传入的 CMS Component 类型，解析出对应的 Angular Component 元数据，而后调用 Angular Component creation API，动态创建 Component 实例并触发渲染流程。

采取这种 CMS 驱动的设计思路，通过 PayLayoutComponent 和 PageSlotComponent 两大容器组件的配合，无论 CMS 管理员在 Backoffice 对一个 Page 待显示的内容进行何种批改，Spartacus UI 端的代码均可能主动应答这些批改，做到以不变应万变。

本文概述了 SAP WebClient UI，SAP Cloud for Customer 和 SAP Commerce Cloud Spartacus UI 中容器组件的设计和运行原理。集体认为，学习 SAP 某个产品的 UI 开发，只有把握了其一般 UI 组件 (参考我的文章：谈谈 SAP 产品 UI 开发中的组件概念) 和容器组件的概念和开发方式，就足以胜任大多数场合下的工作需要了。

Jerry 后续将带来更多对于 SAP UI 开发技术的分享，敬请期待。

更多浏览