共计 3351 个字符，预计需要花费 9 分钟才能阅读完成。
本文首先疾速回顾几种 SAP 产品中的 UI 加强思路，而后具体介绍该思路是如何在 SAP Commerce Cloud(电商云) UI 加强中贯彻实施的。
Jerry 之前的文章：Jerry 在 2020 SAP 寰球技术大会的分享：SAP Spartacus 技术介绍的文字版 ，已经提到，SAP 电商云的新一代规范 UI，由泛滥 Angular Component 组成，这些 Component 通过 SAP Spartacus 开源我的项目，以库文件的形式公布给客户应用。
客户通过在 Angular 利用的 package.json 里，导入 @spartacus/storefront 的依赖，就能够拜访到 SAP 电商云的规范 UI Component.
Jerry 之前的文章 从一个理论的例子登程，谈谈 SAP Commerce Cloud(电商云) 的 UI 自定义开发 ，介绍了 SAP 电商云 UI 二次开发的形式之一：基于 UI Component 的替换。
咱们假如 SAP 电商云 UI 由 SAP 规范公布的 Angular Component A, B, C, D… 组成，Jerry 文章介绍的二次开发形式，分享了 Partners 如何开发新的 Angular Component A’, B’, C’, D’…，而后如何通过配置通知 SAP Commerce Cloud UI，运行时应用 A’, B’, C’, D’ 来渲染 UI.
本文会介绍 SAP 电商云另一种 UI 加强形式，不是通过开发新的 Component A’ 去替换 A，而是间接对 A 做加强，比方增加一个新的字段 a, 嵌入到 Component A 中，这样 A 就成为了 Aa .
这种在原有 UI 根底上增加新字段的加强形式，并非 SAP 电商云特有，在 SAP 很多其余产品里也能看到。
Jerry 之前的文章 SAP 产品加强技术回顾 ，已经回顾过 SAP 产品包含字段和流程在内的加强技术。就界面字段加强而言，比方 SAP CRM 里，咱们能够先创立一个数据库表，插入一些数据进去，而后利用 AET(Application Extension Tool)，创立一个新的扩大字段 JVM Type，类型为下拉列表，下拉列表中的内容来自咱们自定义的数据库表。
在应用 SAP CRM AET 创立扩大字段之前，先要抉择基于哪一个 BO 的哪一个节点来创立，即抉择 Object Part.
创立好的类型为下拉列表的 CRM 扩大字段如下：
下图则是 SAP Cloud for Customer 加强字段的创立界面。Business Context 是一组能被扩大的 UI 界面的逻辑形象，针对某个 Business Context 创立的扩大字段，会主动呈现在对应的 UI 界面上。这个术语 Business Context 在 SAP Commerce Cloud 里会再次出现，只是换了个称说，叫做 Outlet.
至此，咱们曾经理解了 SAP CRM 里的 Object Part，以及 SAP Cloud for Customer 里的 Business Context，这些概念都是用于界定待创立的加强字段的上下文，即加强字段呈现在 UI (以及其余模型，比方 BO，接口等) 的具体位置。
到了 SAP CRM Fiori 利用里，加强字段上下文的称说变成了：Extension Point.
看一个我之前领导 Partners 实现的理论加强需要。
Sales Office 和 Sales Group 是 SAP CRM WebClient UI 上的规范字段：
然而这两个字段并未呈现在对应的 CRM Fiori 利用里。
不过，Partners 依然能够利用该 Fiori 利用 UI 上预留的 ExtensionPoint，即 salesAreaInfoTabContentBottomExtension，来自即将这两个字段增加到 Fiori UI 上：
Partners 自行创立一个 view fragment，外面蕴含 Sales Office 和 Sales Group 两个字段：
而后将该 view fragment 配置到 salesAreaInfoTabContentBottomExtension 上即可。最初，蕴含在 view fragment 里的自定义字段，就会呈现在 Fiori 利用 Sales Area 面板的对应地位，如下图所示：
至此，咱们理解到的 SAP 产品里定义扩大字段上下文的术语列举如下：
- SAP CRM：Object Part
- SAP Cloud for Customer：Business Context
- SAP CRM Fiori：ExtensionPoint
通过以上形式在 SAP 规范 UI 上创立的加强字段，并不是通过间接批改规范 UI 源代码的形式实现的。加强字段同被加强的 UI 相比，二者物理上是不同的模型，存储逻辑也各不相同，因而这种加强形式是降级平安的，即便规范 UI 发生变化，只有扩大字段上下文保持稳定，则被加强 UI 上的这些扩大字段，不会受到 SAP 规范 UI 降级或者故障修复的影响。
上面是扩大字段上下文概念在 SAP Commerce Cloud 里的称说：Outlet. 有了后面这么多铺垫，也就不难理解 SAP Commerce Cloud UI 的字段加强形式的工作原理了。
下图彩色区域是 SAP 电商云的 footer 区域，假如咱们须要在 footer 区域的顶部和尾部，再削减一些自定义字段。换个更技术一些的说法，咱们须要基于自定义字段上下文，即 Outlet = footer 的 UI 区域，创立一些自定义字段。
具体做法：在 Chrome 开发者工具里找到 footer 区域的 ID：cx-footer.
创立一个新的 Angular Component(类比 SAP CRM Fiori 的 View Fragment)，在外面应用 cxOutletRef 指令，将两个新的字段 before footer 和 after footer，关联到 ID 为 cx-footer 的 Outlet 上 (类比 SAP CRM Fiori 的 ExtensionPoint)，呈现的地位别离用 cxOutletPos 指定成 before 和 after，即心愿这两个扩大字段，别离呈现在 SAP Commerce Cloud footer 区域之前和之后。
这两个扩大字段最初运行时的显示成果：
同 SAP 其余产品相比，因为 SAP Commerce Cloud UI 基于 Angular，所以借助 Outlet，不仅能够像 SAP CRM Fiori 那样，通过插入一般的 HTML 标签来增加加强字段，而且能应用 Angular 模板表达式，达到增加新的逻辑的目标。
比方我在 SAP Commerce Cloud 产品明细页面，基于 ProductDetailsPageTemplate 这个 Outlet 创立了两个新的字段，一个字段为 h1 动态标签，另一个 p 标签的内容，应用 Angular async 管道订阅 product$, 再以 json 格局显示以后产品的全副数据：
以后产品的数据明细，绑定到 product$ 上，一个 Observable 对象，通过注入的 CurrentProductService 服务调用 getProduct 办法返回。
最初运行时的两个加强字段，在 SAP 电商云产品明细页面显示的成果如下：
至此，本文通过 SAP CRM，SAP Cloud for Customer，SAP CRM Fiori，以及 SAP Commerce Cloud 产品里创立扩大字段来实现 UI 加强需要的逐个介绍，给大家展现了 SAP 产品一脉相承的 UI 加强思路。
实际上 SAP 这些产品的加强形式，只有弄清楚其中一个产品的加强实现细节，再学习其余 SAP 产品时就容易触类旁通了。
大家如果对 SAP Commerce Cloud 新一代基于 SAP Spartacus 框架的 UI 加强有任何疑难或者需要，欢送分割自己。我会收集大家的反馈，分享给我的团队。
感激浏览。
更多浏览
- Jerry 在 2020 SAP 寰球技术大会的分享：SAP Spartacus 技术介绍的文字版
- SAP 产品的 Field Extensibility
- 基于 SAP Kyma 的订单编排加强介绍
- SAP Cloud for Customer Extensibility 的设计与实现
- 从一个理论的例子登程，谈谈 SAP Commerce Cloud 电商云的 UI 自定义开发
- SAP Commerce Cloud (电商云) UI 的懒加载性能
- SAP CRM Fiori 利用和 SAP Commerce Cloud (电商云) UI 如何通过调整 CSS 来扭转 UI 显示格调
- SAP 产品加强技术回顾
更多 Jerry 的原创文章，尽在：” 汪子熙 ”:
