Fiori和WebUI相比，一個突出feature是支援bookmark，即Fiori裡view的每個狀态都有一個unique的url與之對應-technical 文檔上将url稱為hash，而Webui就不支援，stateful的application，所有狀态的url都不變。
Example：
display view: https://jerry: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: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個毫無必要。
