SAP UI 搜索分页技术

  • 时间:
  • 浏览:0
  • 来源:大发5分6合APP下载_大发5分6合APP官网

下面是菜园子小哥王聪的讲解。还是老规矩,您能不到点击文末的"阅读原文”,获取王聪的中英德4个 版本的讲解文章。

原先台通过UI5库文件发送的饱含 $skip和$top参数的OData请求,被后台接收并维护于io_query_options参数中:

要获取更多Jerry的原创技术文章,请关注公众号"汪子熙"将会扫描下面二维码:

像国内的知乎,简书,新浪微博哪几种网站,其列表显示均实现了懒加载。菜园子小哥王聪对哪几种实现也很好奇。为哪几种最后选泽了Twitter去研究?这就得从他和基友老金的故事说起。

这里亲戚大伙进入到请求成功的措施中继续探索。最终到达终点,items_html被加在到了时间轴当中。

位(Position): 每根绳子 推文的标识符,说白了就让推文的ID。新推文的Position比老推文的要大,某些我真是Position很有将会代表着“这是Twitter有史以来的第xxx条推文”。可我随便找到的4个 Position却真是大得我让你怀疑本人的猜测。

服务器为甚知道应该渲染第二页的源代码呢?你你這個信息也是点了“2”页码后,原先台传给ABAP服务器的:

看着老金整天闷闷不乐,我便安慰你说歌词 哪几种长微博,不就让文字变图片嘛。Twitter没这东西,看小爷我的本事啊。我我就写个App,名字就叫“大Twitter”,图标我都我就设计好了。

下图例子里,我指定Max Number of Results为3000,意思是期望满足搜索条件的记录里,显示3000条到UI上。

Paging Implementation in S/4HANA for Customer Management

上图第1674行@lv_offset的值,是基于UI传入的$skip和$top计算而得。

Jerry的通过CDS view + Smart Template 开发Fiori应用的blog合集

起初我以为后端会根据都要即将响应的内容大小决定发好多个条,可分析了某些例子就让发现有的就让响应明明很小,却还是发了不到20条。某些我的猜测是后端你你這個神奇的算法将会会判断返回的内容用户最少 会浏览多久,将会比较耗时,则少返回某些。這個将会推文饱含 长视频,则判断为阅读耗时较长,能不到少返回好多个。但这就让我瞎猜的,有知道其中原理的亲戚大伙能不到留言我就让知道,非常感谢。

我拿来一看,原先是老金真是憋了太满,你你這個次足足写了8300多个字,生成的图片尺寸过大,被鸡贼的Twitter给压缩了,于是便模糊得像打了码一样。心灰意冷的老金决定与Twitter恩断义绝,连账户都撤除了。

(2) 由应用开发人员根据$skip和$top值,将多余的记录丢弃掉,保证最后只返回20条记录给UI。

CRM Fiori后台的搜索分页解决和S/4HANA Fiori的区别:并未使用ABAP的OFFSET关键字,而由应用开发人员自行实现。

该搜索分页的实现归功于OData请求的参数,$skip=0&top=25,意为从请求命中的第0条记录就让刚结束了了, 总共返回25条记录。而原先参数$inlinecount,其工作原理能不到借喻ABAP Open SQL的关键字SELECT COUNT(*),用于统计数据库表的条目数。

那min_position和max_position呢?亲戚大伙回到刚才定义请求的位置继续向上追溯,找到了getOldItems的措施。当用户在时间轴上向下滚动鼠标到最后时,就会调用到你你這個措施,而在其中会把上一次响应当中的min_position赋值给你你這個次请求当中的max_postion。

坦率讲整个Debug过程花费了我某些时间,一方面是对于其代码价值形式的不想太熟悉,本人面是minify过的js代码真是是我就头疼啊。所有的变量都长成abcd不说,到处都不 用逻辑运算符写的条件判断得话,看过口吐白沫。

老金痛恨Twitter。

以S/4HANA Product Master Fiori应用为例,将会哪几种搜索条件都不 指定,默认会返回25条数据,就让 在UI上显示该系统总的product数量,在Jerry使用的系统里总共发生140个product。

在研究的过程中,我发现了4个 有趣的疑问报告 ,就让new_latent_count绝大多数都不 20,而偶尔会略小于20。将会前端请求中不想发生所要请求的条数,某些你你這個决策是在后端完成的。

S4CRM,全称为S/4HANA for Customer Management,UI开发技术仍然采用WebClient UI。和S/4HANA基于UI5的前端技术截然不同,WebClient UI走的是服务器端渲染的BSP路线。严格意义上讲,WebClient UI不发生数据库层面的搜索分页,其分页行为仅仅体现在服务器端渲染上。

在这里亲戚大伙能不到发现好多个有意义的信息:

首先亲戚大伙在开发者工具的Network工具中截取每根绳子 当用户滚动加载时发出的请求。结果发现它长下面你你這個样子。

上图的$skip和$top参数同S/4HANA应用的行为相同,传递到后台并得到解决:

真是我就让为甚用Twitter,但作为4个 系统线程池池员我对它还是很有兴趣的。作为這個产品中的佼佼者,Twitter自然是有它的优势。其中比较有特色的某些就让其懒加载的机制。今天亲戚大伙就通过Debug的措施来对其探究一番。

至此S/4HANA和CRM Fiori应用的搜索分页原理介绍完毕。更多细节,请参考我的博客:

再来看看搜索分页的后台解决。在Netweaver事务码ST05的数据库跟踪视图里,能清晰观察到你你這個分页效果:每次到数据库的查询只命中并返回25条记录,如下图三条高亮的跟踪记录所示。

了解了咱们SAP的搜索分页实现原理后,让亲戚大伙再来看看某些厂商是为甚做的。

可没想到,老金刚用了半天就找到我,说本人写的东西我就让知道为哪几种全被打上了马赛克,并信誓旦旦对“秦老师”发誓说本人没写哪几种大尺度的东西。我问他秦老师是谁?你说歌词 是印度著名诗人秦戈尔老师啊!善良的我并没法 当面给他指出那位老师不姓秦这件事,只想着好好的图片为甚会被打码了呢?

搜索分页技术往往和原先术语Lazy Loading(懒加载)联系起来。今天由Jerry首先介绍S/4HANA,CRM Fiori和S4CRM应用里的UI搜索分页的实现原理。后半累积由SAP成都研究院菜园子小哥王聪向您介绍Twitter的懒加载实现。

Search Paging implementation in S/4HANA and CRM Fiori application

为哪几种分页的尺寸为25?在Fiori UI列表实现文件sap.m.ListBase.js里,默认的分页尺寸(GrowingThreshold)为20,这说明一定发生某个配置,将会在Product Master应用某处的JavaScript代码将你你這個分页尺寸从20改成了25。

更多渲染细节,请参考我的博客:

ABAP后台拿到你你這個visibleFirstRow参数后,知道从搜索结果记录里的第21条就让刚结束了了渲染,时不时到第40条。

(1) 首先将所有满足搜索条件的记录的GUID完全从数据库取出,从数据库层返回到ABAP层。在我你你這個测试系统里,总共有21条记录,完全返回到了ABAP层:

以及使用Smart Template开发Fiori应用的介绍:

CRM Fiori应用的前台搜索分页实现原理和S/4HANA Fiori应用這個,就让分页尺寸变成了20。

从搜索结果能看出分页效果。完全3000条记录将会从数据库查询出来并保存到应用系统线程池池的内存里。如下图所示:

How does UI5 AutoGrowing list(Lazy Load behavior) work

而最终在数据库查询层面的分页解决,是由ABAP Open SQL的关键字OFFSET实现的。



将会您想通过本人调试找到你你這個答案,锻炼本人的分析能力,能不到参考我的调试过程:

老金是我在德国读书时的好基友,在国内时就酷爱文学创作。但他却从未开通个博客哪几种的,坚持使用新浪“长微博”功能写文章。用他得话说,这代表新锐文学的姿态。到了德国就让,老金发现人家网友 不想微博,人家用Twitter。新锐的他自然要入乡随俗,可正准备舞文弄墨,却发现Twitter里并没法 个东西叫“Long Twitter”,140个字符啥也干不了。于是老金愤而卸载Twitter,逢人便感慨西方文学这下是要彻底完了。

将会篇幅限制,Jerry直接揭晓答案了。S/4HANA里的Fiori应用都不 使用Smart Template技术实现的,其列表区域的实现发生SmartTable.fragment.xml你你這個模板文件里,growingThreshold指定为25。将会从时间序列上来说SmartTable.fragment.xml后于sap.m.ListBase.js加载,某些对于分页尺寸的定义其优先级更高。

时间轴(Time Line): Twitter中最最重要的累积。每根绳子 条的推文组合在一齐,就成了页面上中间那条长长的时间轴。

不过从学习的深度1讲,整个过程跑下来无论是debug能力还是代码阅读能力都不 有所提升,推荐亲戚大伙也试一试。

为了搞清楚哪几种信息到底是为甚回事,亲戚大伙通过寻找请求的发起者来深入到代码当中。原先Twitter在这里发送了4个 XMLHttpRequest。无论是哪几种请求,总归要有4个 解决的措施,亲戚大伙在Call Stack中层层向上追溯,就让 找到了请求的定义位置。

WebClient UI仅仅将第一页的HTML源代码在ABAP后台渲染出来就让 显示给用户。当用户点了屏幕下方的“2”页码时,不想有任何的数据库查询发生,服务器做的事情仅仅是将第二页对应的HTML源代码渲染出来。

关于王聪的背景介绍,您能不到参考他的前一篇文章:SAP成都研究院非典型系统线程池池猿,菜园子小哥:当我用UI5诊断工具时我用些哪几种。

一旦用鼠标滚轮向下移动页面至屏幕底部,会自动触发4个 新的OData请求,参数为$skip=25&top=25。 原先,从第26到第3000个product也从数据库表中读取出来显示在Fiori UI上。

就让 我用了4个 晚上搞了个小工具,把大段文字转成图片,就让 直接发到Twitter上。

至此亲戚大伙能不到将整个Twitter的懒加载流程串接起来: