摘要：从调用栈能清楚发现是这个事件触发的第二批的读取动作。然后再去这一个调用栈，发现一个属性维护了一个开始索引，每次到底部的事件触发之后，该属性值都会被累加。这些库文件一览在开发者工具查看从后台加载的库文件，能发现属性在此处被硬编码成。
今天一同事问我这个问题：S/4HANA Fiori应用里的列表，一旦Scroll到底部就会自动向后台发起新的请求把更多的数据读取到前台显示。
以Product Master这个应用为例，我点击搜索之后，结果区域显示当前系统一共有140个product，但是只有前25个返回并显示在浏览器里。
这个分页效果是UI5 OData的参数实现的：$skip=0&top=25。
而总数140，是通过参数$inlinecount实现，其原理和ABAP Open SQL的SELECT COUNT(*)类似。
从Chrome开发者工具能观察到头25个product的payload：
当将列表滚动至底部时，第二批共25个product从后台读取出来，显示在前台：
这个http请求的参数：$skip=25&top=25，用于读取从第25个到第50个product。
从调用栈能清楚发现是scroll这个事件触发的第二批product的读取动作。
然后再去GrowingEnablement.requestNewPage这一个调用栈，发现一个属性_iLimit维护了一个开始索引，每次scroll到底部的事件触发之后，该属性值都会被GrowingThreshold累加。 因为API this._oControl.getGrowingThreshold每次返回的是一个常量25, 因此_iLimit的值每次scroll到底部之后看起来是这样的：25,50,75,100 ... 这些值会被用来作为HTTP请求参数$skip的值传到后台：
我同事的问题：growingThreshold在文件sap.m.ListBase.js里被硬编码成20, 但是运行时在何处被改写成了25？
要回答这个问题，需要了解一些UI5 Smart Template的知识，因为例子里这个Product Master的Fiori应用，也是基于Smart Template开发的。可以参考我的博客My understanding about how object page in Smart Template is rendered 来了解其工作原理。
当Product Master这个应用的UI Component被加载并马上开始渲染时，需要先加载Smart Template的库文件:
在我博客My understanding about how object page in Smart Template is rendered 提到，ListReport.view.xml这个文件里有若干view fragment的声明，每个声明指向了一些其他的Smart Template库文件。
这些库文件一览：
在Chrome开发者工具查看从ABAP后台加载的库文件SmartTable.fragment.xml，能发现属性growingThreshold在此处被硬编码成25。
当SmartTable.fragment.xml被加载之后其内容会被解析， growingThreshold值为25，会通过控件的setter API写入到控件属性里。这样接下来在处理列表的scroll事件是，25这个值就会通过控件的getter API返回并累加到_iLimit上。
关于XML view从ABAP后台加载到浏览器后是如何被解析并生成对应的UI5控件，可以参考我的博客Why my formatter does not work? A trouble shooting example to know how it works
也许您按照我上面描述的步骤操作，但是无法触发断点。原因是因为UI5框架针对基于Smart Template开发的Fiori应用的XML view设计了一套缓存机制。当待渲染的XML view已经在缓存中存在时，不会去ABAP后台加载Smart Template的库文件, 而是直接执行第428行的IF分支。
通过调试我们可以发现缓存是通过IndexedDB加上LRU(Least recently used)算法实现的。
通过Chrome开发者工具可以观察到待渲染的view已经有记录存储在IndexedDB里了：
如果想观察Smart Template库文件的加载，需点击"Delete database"以手动清除缓存。
缓存清除完毕后，即可观察到期望中的Smart Template库文件加载。
这篇文章介绍了如何通过调试找到同事提出问题的答案。我把它加在了我UI5调试文章分享的合集里：My UI5 debugging tips and experience collection - how to resolve UI5 issues through debugging by yourself
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/68898.html
摘要：从调用栈能清楚发现是这个事件触发的第二批的读取动作。然后再去这一个调用栈，发现一个属性维护了一个开始索引，每次到底部的事件触发之后，该属性值都会被累加。这些库文件一览在开发者工具查看从后台加载的库文件，能发现属性在此处被硬编码成。 今天一同事问我这个问题：S/4HANA Fiori应用里的列表，一旦Scroll到底部就会自动向后台发起新的请求把更多的数据读取到前台显示。 以Produc...
摘要：从调用栈能清楚发现是这个事件触发的第二批的读取动作。然后再去这一个调用栈，发现一个属性维护了一个开始索引，每次到底部的事件触发之后，该属性值都会被累加。这些库文件一览在开发者工具查看从后台加载的库文件，能发现属性在此处被硬编码成。 今天一同事问我这个问题：S/4HANA Fiori应用里的列表，一旦Scroll到底部就会自动向后台发起新的请求把更多的数据读取到前台显示。 以Produc...
摘要：搜索分页技术往往和另一个术语懒加载联系起来。该搜索分页的实现归功于请求的参数，，意为从请求命中的第条记录开始总共返回条记录。更多细节，请参考我的博客应用的搜索分页实现原理，全称为，开发技术仍然采用。 搜索分页技术往往和另一个术语Lazy Loading（懒加载）联系起来。今天由Jerry首先介绍S/4HANA，CRM Fiori和S4CRM应用里的UI搜索分页的实现原理。后半部分由SA...
阅读 1038·2021-11-18 13:23
阅读 745·2021-11-08 13:16
阅读 854·2021-10-11 10:58
阅读 3509·2021-09-22 15:26
阅读 1730·2021-09-08 10:42
阅读 1806·2021-09-04 16:45
阅读 1732·2019-08-30 15:54
阅读 2563·2019-08-30 13:45
