Sent: Monday, March 7, 2016 19:28

Figure1: 在Faas 系統里看不到quick create的input field

在我們on premise系統上無法重現這個問題。

Figure2: on premise 平臺上 input field是顯示正常的

我處理的思路是：

起初我懷疑quick create的field 在html source里根本未生成，但是用Chrome dev tool排除了這個可能性。

然后懷疑quick create的dom height render出來為0(之前處理過類似的incident)，但是這個可能性也用Chrome dev tool排除了。

既然dom element 存在，高度也是40px, 為什么就是沒顯示出來？

印度人在S2.controller.js里fixDisplayOfDirectInput有一大串眼花繚亂的計算:
計算的輸入是: （如下圖所示）
n ScrollContainer的相對Y坐標
n Quick create input的高度
n Footer bar的高度
n 整個window的高度

輸出是計算出來的ScrollContainer的Height。

我在印度人的計算邏輯里沒有發現問題，然后逐一比對FaaS和GM0上相關dom的CSS style，沒有任何區別。
然后我自己加了大量log打印每個html element的height，FaaS和GM0也沒任何區別。

當打印到每個element的相對Y坐標，就是OffsetTop時，就發現問題了。
每次我上下拖動UI 讓resize handler觸發時，進入fixDisplayOfDirectInput(), 然后我打印footer和input的相對y坐標。
在工作正常的GM0上，兩者的差正好是input field的height。

而在Faas上，兩者的差在5px以下，這說明他們的layout互相重疊了，Footer bar遮住了input field，從end user眼中看，就像是input field消失了。
可以通過在Development tool里將footer bar對應的dom 刪除的方式來驗證。刪除footer bar之后，input field立即就顯示出來了。

然后需要找到為什么兩個element會重疊的原因。仔細觀察Faas的UI，發現和on premise Launchpad不同，在my task application的toolbar下面，還有一個Faas的toolbar：

這個toolbar是Faas 框架用JS創建的：

印度人的計算邏輯里，沒有考慮到這種scenario。當我在debugger里動態修改代碼，把Fass toolbar height從計算出的height里扣掉之后，

FaaS上也能夠work了。這里的50是一個hard code的值，代表faas footer bar的高度。

這個solution里如何判斷是否有額外的footer bottom bar成為了關鍵。

考慮到絕大多數的客戶即使需要擴展toolbar，也會使用我們的extension point declare新的button放進existing toolbar里，而不是創建全新的toolbar，因此為了handle Faas這種情況，
我認為下面的solution足矣。

即使是在local tomcat里run，例如我們從task list navigate到task detail，然后再navigate后來，此時我們會發現$(“footer”)返回兩個element，一個是當前active的S2 的footer，另一個是task detail的footer element，盡管此時task detail沒有在UI上顯示出來，但是在Chrome development tool里的Element tab里仍然能夠找到這個element。

因此用這種length為2的辦法不能作為判斷是否是Faas系統的依據。

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":

總結

以上是生活随笔為你收集整理的Fiori as a Service - FaaS - Creation of inline task option is not available的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。