Fiori应用的书签模式 - bookmark

Fiori和WebUI相比,一个突出feature是支持bookmark,即Fiori里view的每个状态都有一个unique的url与之对应-technical 文档上将url称为hash,而Webui就不支持,stateful的application,所有状态的url都不变。 Example: display view: https://jerry.sap.corp:4080/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html#Lead-manageLead&/detail/Leads(guid’FA163E8E-AB03-1EE5-818B-CF04EB3503A5’) Edit view: https://jerry.sap.corp:4080/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html#Lead-manageLead&/edit/Leads(guid’FA163E8E-AB03-1EE5-818B-CF04EB3503A5’)

Issue: 如果客户把Edit view的url存到收藏夹里,下次通过收藏夹直接打开edit view.修改Lead,能成功save,但是这种bookmark的scenario下S3 没有实例化,所以执行window.history.go(-1), 直接跳到浏览器的主页去了。。。

这个bookmark的功能又引入另外一个consideration:附件邮件里,做Faas performance test的德国同事认为现在My opportunity application第一次launch的时候,就会到后台取priority,user status,sales stage等等dropdown list里的entry,他们认为没必要,应该延迟到user真正点edit button时再取。但是bookmark的scenario里,没有edit button的点击动作,page一render好马上就是edit mode,这种情况下怎么实现dropdownlist entry的retrieve还需要仔细考虑。

2. 每次在Lead edit page做了修改点击save button后,会navigate到display view,在display view里重新取Products, change Docs, LeadLogs.

这个取数据的动作是由我们代码里注册了一个event handler trigger的。现在由于代码的bug,会造成每次save操作时,会不断地call attachEvent方法 注册取数据的操作,而没有detachEvent去移除,会造成第N次save lead之后,会带来N+1次重复取上述数据。下图是一个例子:我第4次修改lead,造成往后台发5个一模一样的Odata request,虽然是异步的,但后面4个毫无必要。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

编辑于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券