資訊專欄INFORMATION COLUMN
摘要：從調(diào)用棧能清楚發(fā)現(xiàn)是這個事件觸發(fā)的第二批的讀取動作。然后再去這一個調(diào)用棧，發(fā)現(xiàn)一個屬性維護了一個開始索引，每次到底部的事件觸發(fā)之后，該屬性值都會被累加。這些庫文件一覽在開發(fā)者工具查看從后臺加載的庫文件，能發(fā)現(xiàn)屬性在此處被硬編碼成。
今天一同事問我這個問題：S/4HANA Fiori應(yīng)用里的列表，一旦Scroll到底部就會自動向后臺發(fā)起新的請求把更多的數(shù)據(jù)讀取到前臺顯示。
以Product Master這個應(yīng)用為例，我點擊搜索之后，結(jié)果區(qū)域顯示當(dāng)前系統(tǒng)一共有140個product，但是只有前25個返回并顯示在瀏覽器里。
這個分頁效果是UI5 OData的參數(shù)實現(xiàn)的：$skip=0&top=25。
而總數(shù)140，是通過參數(shù)$inlinecount實現(xiàn)，其原理和ABAP Open SQL的SELECT COUNT(*)類似。
從Chrome開發(fā)者工具能觀察到頭25個product的payload：
當(dāng)將列表滾動至底部時，第二批共25個product從后臺讀取出來，顯示在前臺：
這個http請求的參數(shù)：$skip=25&top=25，用于讀取從第25個到第50個product。
從調(diào)用棧能清楚發(fā)現(xiàn)是scroll這個事件觸發(fā)的第二批product的讀取動作。
然后再去GrowingEnablement.requestNewPage這一個調(diào)用棧，發(fā)現(xiàn)一個屬性_iLimit維護了一個開始索引，每次scroll到底部的事件觸發(fā)之后，該屬性值都會被GrowingThreshold累加。 因為API this._oControl.getGrowingThreshold每次返回的是一個常量25, 因此_iLimit的值每次scroll到底部之后看起來是這樣的：25,50,75,100 ... 這些值會被用來作為HTTP請求參數(shù)$skip的值傳到后臺：
我同事的問題：growingThreshold在文件sap.m.ListBase.js里被硬編碼成20, 但是運行時在何處被改寫成了25？
要回答這個問題，需要了解一些UI5 Smart Template的知識，因為例子里這個Product Master的Fiori應(yīng)用，也是基于Smart Template開發(fā)的?？梢詤⒖嘉业牟┛蚆y understanding about how object page in Smart Template is rendered 來了解其工作原理。
當(dāng)Product Master這個應(yīng)用的UI Component被加載并馬上開始渲染時，需要先加載Smart Template的庫文件:
在我博客My understanding about how object page in Smart Template is rendered 提到，ListReport.view.xml這個文件里有若干view fragment的聲明，每個聲明指向了一些其他的Smart Template庫文件。
這些庫文件一覽：
在Chrome開發(fā)者工具查看從ABAP后臺加載的庫文件SmartTable.fragment.xml，能發(fā)現(xiàn)屬性growingThreshold在此處被硬編碼成25。
當(dāng)SmartTable.fragment.xml被加載之后其內(nèi)容會被解析， growingThreshold值為25，會通過控件的setter API寫入到控件屬性里。這樣接下來在處理列表的scroll事件是，25這個值就會通過控件的getter API返回并累加到_iLimit上。
關(guān)于XML view從ABAP后臺加載到瀏覽器后是如何被解析并生成對應(yīng)的UI5控件，可以參考我的博客Why my formatter does not work? A trouble shooting example to know how it works
也許您按照我上面描述的步驟操作，但是無法觸發(fā)斷點。原因是因為UI5框架針對基于Smart Template開發(fā)的Fiori應(yīng)用的XML view設(shè)計了一套緩存機制。當(dāng)待渲染的XML view已經(jīng)在緩存中存在時，不會去ABAP后臺加載Smart Template的庫文件, 而是直接執(zhí)行第428行的IF分支。
通過調(diào)試我們可以發(fā)現(xiàn)緩存是通過IndexedDB加上LRU(Least?recently?used)算法實現(xiàn)的。
通過Chrome開發(fā)者工具可以觀察到待渲染的view已經(jīng)有記錄存儲在IndexedDB里了：
如果想觀察Smart Template庫文件的加載，需點擊"Delete database"以手動清除緩存。
緩存清除完畢后，即可觀察到期望中的Smart Template庫文件加載。
這篇文章介紹了如何通過調(diào)試找到同事提出問題的答案。我把它加在了我UI5調(diào)試文章分享的合集里：My UI5 debugging tips and experience collection - how to resolve UI5 issues through debugging by yourself
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/68898.html
摘要：從調(diào)用棧能清楚發(fā)現(xiàn)是這個事件觸發(fā)的第二批的讀取動作。然后再去這一個調(diào)用棧，發(fā)現(xiàn)一個屬性維護了一個開始索引，每次到底部的事件觸發(fā)之后，該屬性值都會被累加。這些庫文件一覽在開發(fā)者工具查看從后臺加載的庫文件，能發(fā)現(xiàn)屬性在此處被硬編碼成。 今天一同事問我這個問題：S/4HANA Fiori應(yīng)用里的列表，一旦Scroll到底部就會自動向后臺發(fā)起新的請求把更多的數(shù)據(jù)讀取到前臺顯示。 以Produc...
摘要：從調(diào)用棧能清楚發(fā)現(xiàn)是這個事件觸發(fā)的第二批的讀取動作。然后再去這一個調(diào)用棧，發(fā)現(xiàn)一個屬性維護了一個開始索引，每次到底部的事件觸發(fā)之后，該屬性值都會被累加。這些庫文件一覽在開發(fā)者工具查看從后臺加載的庫文件，能發(fā)現(xiàn)屬性在此處被硬編碼成。 今天一同事問我這個問題：S/4HANA Fiori應(yīng)用里的列表，一旦Scroll到底部就會自動向后臺發(fā)起新的請求把更多的數(shù)據(jù)讀取到前臺顯示。 以Produc...
摘要：搜索分頁技術(shù)往往和另一個術(shù)語懶加載聯(lián)系起來。該搜索分頁的實現(xiàn)歸功于請求的參數(shù)，，意為從請求命中的第條記錄開始總共返回條記錄。更多細節(jié)，請參考我的博客應(yīng)用的搜索分頁實現(xiàn)原理，全稱為，開發(fā)技術(shù)仍然采用。 搜索分頁技術(shù)往往和另一個術(shù)語Lazy Loading（懶加載）聯(lián)系起來。今天由Jerry首先介紹S/4HANA，CRM Fiori和S4CRM應(yīng)用里的UI搜索分頁的實現(xiàn)原理。后半部分由SA...
閱讀 1058·2021-11-18 13:23
閱讀 763·2021-11-08 13:16
閱讀 876·2021-10-11 10:58
閱讀 3523·2021-09-22 15:26
閱讀 1753·2021-09-08 10:42
閱讀 1831·2021-09-04 16:45
閱讀 1747·2019-08-30 15:54
閱讀 2578·2019-08-30 13:45
