差点被dojo搞死

前端之家收集整理的这篇文章主要介绍了差点被dojo搞死前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
做WEB界面编程很痛苦。菜鸟做WEB界面编程比黄连还苦。
Dojo 提供了一个Tooltip Widget。当我们的鼠标移到指定的地方时,一个提示框就弹出来了。
再把Tooltip稍稍扩展一下,就可以在弹出来的Tooltip里放任意HTML代码加上一点AJAX调用,一个内容丰富的提示框就做出来了:
鼠标可以在tooltip里自由移动。鼠标移出tooltip,该tooltip自动消失。够简单吧?可惜接着我就被dojo玩儿死了。
展开任何一个的下拉框,把鼠标移进下拉框。Tooltip立刻消失。难道Ellen Ullman的 The Bug这一刻灵魂附体?
顺藤摸瓜到dojo.widgets.tooltip的代码里。既然跟鼠标移动有关,就找和事件onmousemove有关的代码。很容易地找到了dojo.widgets.tooltip._onMouseMove = function(e){…}。代码很简单,靠一个帮助函数dojo.html.isOnElement(element,e)来判断鼠标的位置是否在Tooltip内。加上一行dojo.debug(…),刷新页面,发现问题所在:当鼠标在一般HTML控件上,比如table,div,select一类,用来判断坐标的mouseEvent.pageX都是鼠标相对于document的坐标。可是当鼠标移动到展开的option下拉框里,坐标就编程相对于包含该option的div的坐标了。怒。不过还好。不就是累加所有mouseEvent.targe和targetParent的(offsetX,offsetY)么:
刷新,再试。“Select size”下拉框可以正常工作了。不过作为一个负责的程序员,不能只测试一种情况吧?于是把鼠标移到了第二个下拉框。我的心立马哇啦哇啦地凉了。鼠标移到第二行选项时,整个tooltip消失乐。
仔细观察了一下,注意到两件事:1. 虽然鼠标移到第二行选项,这一行并没有显示高亮,高亮仍然停留在第一行。2. 这种情况只存在于第二个下拉框。第一个和第三个都没有问题。3. 鼠标的坐标奇迹般地从(600,400)变成了(20,10)。嗯,老实的程序员从来不在遇到问题的时候怀疑工具和机器,所以我开始沉痛检讨自己的程序。多加一条dojo.debug后,发现虽然鼠标在下拉框里,丫对应的MouseMove.target居然是HTMLSelectElement!也就是说,牛皮轰轰的浏览器把下拉框背后被遮盖的select控件框当成MouseEvent.target返回,而MouseEvent.pageX/Y仍然是针对option的相对坐标。而我上面的代码只针对option做了修复,自然跳过了当target为HTMLSelectElement的情况。在if语句里加上 || element instanceof HTMLSelectElement也不行,因为没有重叠时,鼠标移到Select上面产生的MouseEvent.pageX不需要累加targetParent的坐标。更重要的是,为什么会发生这种情况?为什么选项没有高亮显示?现在的自然选择是检查select的代码。纯HTML代码,有点CSS样式,没有问题阿。波利亚老大在 How to Solve It里反复强调的话响起来了: 你已经知道什么?什么肯定有效?什么是已经解决了的相关问题?能排上用场么?嗯,回归原始。一个阳春select肯定没有问题,于是我开始一项一项去掉附加的CSS样式。结果当width被去掉后,问题消失。进一步试用不同的宽度,发现当选项长度超过选项控件长度时,问题就会出现,而且只在配合dojo使用时出现。不爽啊不爽。
墨菲定律说,坏事扎堆。推论就是,测试时,应该在出现问题的时候测试周边情况,多半能发现更多错误。有了上面的经验,自然联想到如果下拉框超出tooltip边界会怎么样?不出所料,鼠标移到超出边界的选项时,下拉框消失了。这个错误应该是dojo的问题:单单比较鼠标和控件的坐标是不够的。当然也可以说是我们的问题:也许tooltip根本就不是设计来做我们这种信息框的。幸好解决方法不难:我们其实不关心鼠标的具体坐标。我们只关心鼠标是不是还在tooltip内的任何一个控件上。既然这样,我们可以找到鼠标所在的控件,然后比较该控件是不是在tooltip里。这个简单。又是累加offsetX和offsetY的问题:
再判断得到的坐标是不是在tooltip内。刷新。嗯,所有情况都正常了。不对,好像过犹不及。现在把鼠标移出tooltip,tooltip也不消失了。以头戗地一分钟。定神一下,不由再次感叹卧春,卧室达春绿。不同的HTML元素可以重叠。所以哪怕鼠标在tooltip之外,它所在的HTML元素(比如DIV)的一角完全可能在tooltip内。于是改为判断四个角都在tooltip内。这步其实不可靠。不过我们在tooltip里只支持简单的HTML form元素,所以还是比较可靠的。这下终于成功了。
靠,其实是俺的幻觉。IE不认HTMLOptionElement,抛出异常。加入跨浏览器的代码。这个终于世界清静了。哪位老大有更好的解决方法么?
教训:
§ UI编程麻烦,处理太多特例。
§ 抽象层泄漏是个现实问题。用不成熟的框架抽象层泄漏就成了不可避免的现实问题。
§UI编程一点都不好玩儿。一个多小时就折腾出这点玩意儿。获得的知识出了UI界就没有任何传承性。说不定这些东西在馒头界早成历史。

猜你在找的Dojo相关文章