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的原创文章，请关注公众号"汪子熙":