使用Chrome debug attachment upload page：从local laptop上选择一个file之后，断点触发：

前端取得user选中的file name：

点Attach button后，触发Application server 的event handler：

从Chrome network tab能观察到，UI向Application server发送了一个http post：

LOOP所有form parts:

从对应的form part里取出file name, file type:

以及实际的文件内容（由于security原因，该form part的内容无法在Chrome的network里观察到）

CRM WebUI的text determination logic:
https://blogs.sap.com/2014/03/07/ui-text-label-determination-logic/

优先级从高到低: Text Repository-> Design layer -> ABAP Dictionary
WebUI configuration determination:
https://blogs.sap.com/2014/03/07/ui-configuration-determination-logic-introduction/

Custom defined configuration优先级高于SAP configuration

Hybris

Hybris里的配置是通过键值对的方式写到配置文件里的，配置文件有三种不同的位置，按照优先级从高到低影响最后runtime该配置的value.
这个优先级的design在我看来很怪，和SAP传统的product设计正好相反：server根目录下的配置文件具有最高的优先级，不同的module folder下的次之，platform folder下的配置文件是配置文件里优先级最低的，最后应用代码提供default value的优先级反而是最低的，这和ABAP里应用程序可以overwrite表里的配置从而设置新的default value的behavior正好相反。

下图是一个例子：如果四个地方设置了不同的default value，最后起作用的反而是根目录下的配置文件: 囧

nodejs里，我们用node命令执行一个module，node在文件系统上找该module的实现文件，也有一系列优先级不同的determination procedure。从debugger里能很清楚看到：