为了让浏览器兼容,哪么如下代码逻辑就会产生了。 不说业务逻辑如何,单说表达式方式的语法。
程序代码background: expression((this.type =='button')?'#8D9CC5':(this.type =='radio'||this.type =='checkbox')?
style:((this.readOnly &&this.readOnly ==true )||(this.disabled &&this.disabled ==true))?"#C9C9CC":"#EAF0F2");
9点前还用手机算了一卦,抽到了下下签。
我想生日这天会这么惨么?结果确实不是诶!但今天就灵验了.
时间就像杀猪刀,全在GE加班了。

相信很多人都遇到过这种情况,尤其是几年前Ajax和一些MVC框架没流行的时候。 由于我这边技术限制的原因,也有些老代码中出现该问题。分析了一下,大致原因如下:

分析: 从上面图中可以看出代码的sequence, 在fiddler2或者其他一些Http 拦截工具中未发现有请求没完成的情况,也没有失败的请求。所以只可能是IE内部的问题,一部分是JS代码的死锁,另一个就是render的未完成。
结论:这个情况是IE的JS引擎自己的问题,可以推理出当两个input源同时渲染一个dom对象的时候,尤其是级联渲染,最有可能造成死锁。所以写代码的时候,记住逻辑分层和顺序尤其重要。 最终问题解决办法是取消同时两部分的渲染,有主页面或者innerfream来渲染,问题解决。
相信目前还是有很多人在使用Extjs的时候使用到了Iframe,而在使用过程中也有些小问题。如标题所示,这也是我遇到的诡异问题之一,经过分析最后的分析和结论如下:

哪么当用户点击完成左边的Menuitem后,刷新完成页面。如果这个时候你直接去右边表格中拖动列,这个问题就出来了。
分析: 直接点击的时候,在拖拽时候拿到的pagex和pagey点是不正确的(请查看extjs 的drag.js)。我当初想到是可能它把左边的iframe1的宽度加进去了,哪么它拿到window对象可能有问题。那如何让它拿到正确呢?
结果: 让Iframe得到焦点。哪么当你设置iframe2.location的时候,记住也要iframe2.focus()一下。
uusam 






