关于sap:深入学习SAP-UI5框架代码系列之八谈谈-SAP-UI5-的视图控件-ID以及其和-Angular-视图的异同

明天是 2021 年 4 月 27 日，周二，SAP 寰球心理健康日。SAP 寰球的员工，明天放假一天。

这不，早在上周五，我所在的 SAP Spartacus 开发团队的开发经理，就贴心地在 Slack 上揭示所有组员，记得享受 “SAP Global Mental Health Day”.

对于 SAP 寰球心理健康日的更多介绍，请参阅 SAP 中国研究院官网公众号这篇文章：SAP 寰球心理健康日 | 为员工提供精力充电的机会！

作为一个程序员，在明天这一额定的假期里，做点什么好呢？我正好趁此机会，持续书写以前尚未实现的一个深刻学习 SAP UI5 框架代码的系列文章。

(0) SAP UI5 利用开发人员理解 UI5 框架代码的意义

(1) SAP UI5 module 懒加载机制

(2) SAP UI5 控件渲染机制

(3) HTML 原生事件 VS SAP UI5 Semantic 事件

(4) SAP UI5 控件元数据的元数据实现

(5) SAP UI5 控件的实例数据批改和读取逻辑

(6) SAP UI5 控件数据绑定的实现原理

(7) SAP UI5 控件数据绑定的三种模式：One Way, Two Way 和 OneTime 实现原理比拟

本文持续填坑。

在文章一个用于 SAP UI5 学习的脚手架利用，没有任何后盾 API 的依赖介绍的 SAP UI5 脚手架里，创立一个 SAP UI5 Button 控件：

文章 SAP UI5 控件渲染机制已经提到，SAP UI5 控件领有对应的渲染器，比方 Button 的渲染器叫做 ButtonRenderer，负责渲染出如下图高亮的 HTML 代码，其中控件 ID 为 __button0.

最近 Jerry 的技术交换群，有敌人问了我一个问题：如何应用原生的 JavaScript 代码，触发 SAP UI5 按钮控件的点击事件处理函数？

我在这篇知乎文章如何应用原生的 JavaScript 代码，触发 SAP UI5 按钮控件的点击事件处理函数里，提供了解决方案：

在文章里我开发了一个例子，三个 SAP UI5 Button 控件的 ID，在渲染出的 HTML 代码里别离为 __button0, __button1 和 __button2.

很容易看出 SAP UI5 控件 ID 的格局为：控件对应的名称前缀，再加上一个计数器。

其中控件前缀名称，例如 Button 控件 ID 的前缀为 button, 该前缀是 SAP UI5 控件元数据的一部分，在文章深刻学习 SAP UI5 框架代码系列之四：SAP UI5 控件的元数据实现里有具体介绍。

而 SAP UI5 控件的全局计数器，保护在字典数据结构 mUIDCounts 里，其中 key 为不同的 SAP UI5 控件元数据里存储的前缀，value 为该类型的 SAP UI5 控件以后的计数器值。

迄今为止，咱们探讨的都是开发人员在创立 SAP UI5 控件实例时，没有显式指定 ID 的情景。

如果开发人员通过构造函数 ID 参数，显式传入一个 ID：

则最初渲染出的 HTML 源代码里，ID 值不再蕴含前缀：

这个逻辑在 SAP UI5 控件对应的原型链节点 ManagedObject 的构造函数里能够分明地看到：

如果开发人员显式指定了控件 ID，则应用该 ID 渲染 HTML
如果开发人员没有指定控件 ID，则应用控件元数据里蕴含的前缀，加上全局计数器主动生成 ID

SAP UI5 控件提供了一个工具办法，sap.ui.getCore().byId，可能依据控件 ID，返回对应的控件实例。

上面的代码，assert 断言语句可能胜利执行：

有的敌人可能会认为，byId 办法最终会交由原生的 DOM API document.getElementById 来执行，事实并非如此。

每个创立好的 SAP UI5 控件实例，都会被增加到 SAP UI5 全局注册表 mElements 中。随后开发人员调用 sap.ui.getCore().byId 时，该办法间接从注册表 mElements 中查问并返回对应的控件实例即可，其效率高于原生 DOM API document.getElementById.

SAP UI5 的控件实例注册过程，实现在 Core.prototype.registerElement 办法里。下图高亮的第 40705 行代码抛出的谬误音讯，也解释了为什么 SAP UI5 不容许两个控件领有雷同的 ID. 办法 this.oConfiguration.getNoDuplicateIds 检测到反复 ID 后，会执行相应的解决逻辑。

Angular 尽管和 SAP UI5 一样，也是单页面利用，并且二者都容许并重度依赖自定义控件 (Angular 里称 Component)，但二者在视图设计上一个较大的差别就是，Angular Component 的视图实现于原生的 HTML 文件 (或者于内联的 HTML 字符串) 里，而非像 SAP UI5 那样，应用 XML 或者 JavaScript 视图来实现本人的页面布局。

因而，一个前端开发人员，仅凭动态浏览 Angular Component 的 HTML 视图源代码，大抵就能判断出最初渲染而成的 HTML 页面源代码：二者相差不大，Angular 没有 SAP UI5 控件渲染器的概念。

例如，下图是 SAP Commerce Cloud 组织架构明细页面 (Organization Unit Detail) 的 HTML 视图源代码：

下图是最终渲染出的在浏览器里观测到的 HTML 源代码，同上图相比差别不大。

而 SAP UI5 XML 视图，特地是引入 Fiori Elements 之后，XML 视图的代码同最初渲染出的 HTML 源代码相比，差别微小。因为渲染过程中，Fiori Elements 依据 SAP OData 上的 Annotation，进行了十分多简单的解决，后续 Jerry 的公众号会具体介绍。

比方一个 SAP Fiori Elements 利用，只用了 7 行代码，定义了一个 Smart List：

最初失去一个蕴含 Filter Bar 的 Smart List：

Angular UI 不像 SAP UI5 那样，偏向于为每一个 HTML 元素调配一个不反复的 ID. 下图是 SAP UI5 的 HTML 源代码，能察看到不少 HTML 元素都有一个 Unique ID，而这种情景不会在 Angular 利用的 HTML 源代码里产生。

然而 Angular 有一个结构化指令 ng-template, 也具备通过 # 符号标注的 ID 属性，配合另一个指令 NgIf，能实现页面布局的条件渲染。下图是一个具体例子：

SAP UI5 也有相似 Angular 这种 Template 设计，在 SAP UI5 里称为 ViewFragment. 在 SAP Fiori Elements 的框架实现里，更是重度依赖了 ViewFragment，它能作为容器，将若干逻辑上相干且具备重用可能性的 SAP UI5 控件包裹在一起，不便多个 XML 视图重用。

Jerry 的后续文章会具体介绍。

心愿本文能帮忙大家对 SAP UI5 控件的 ID 属性有一个更深刻的意识，感激浏览。