锁定老帖子 主题:EXT的destroy方法是不是存在漏洞?
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-03-18
谢谢2位 你们提供的线索很重要啊 呵呵
我打算想办法改写一下ext的这个问题 到时候有不明白的还要请教2位 谢谢了先 另外最近我的一个工作就是优化ext (减少EXT对内存和cpu资源的占用) 由于之前并不是很了解ext的架构 所以想听听大家的建议 希望有同好者可以和我一起研究 谢谢了 |
|
返回顶楼 | |
发表时间:2008-03-18
我刚才看了一下 purgeElement 方法到最后还是调用了 stopLisener吧
===================== (又仔细看了一下 没掉 呵呵 un方法调用了 但是destroy里的那个 removeAllLisener没有调 呵呵 我看错了 ) 我觉得问题的关键是 ext的一个地方设计的有问题 他应该先 wrap 后备份 也就是说 ext-base.js 第240行的 var wrappedFn = function(e) { return typeof Ext != 'undefined' ? fn(Ext.lib.Event.getEvent(e)) : false; }; 这个操作应该早做 不应该在这一部里做 应该在 eventmanage.js 里的 addListener(205行)里做 先wrap 之后完全操作的是这个wrap之后的function |
|
返回顶楼 | |
发表时间:2008-03-18
觉的还是这2行的问题
fn._handlers = fn._handlers || []; fn._handlers.push([Ext.id(el), ename, h]); 这里的_handlers只在Eventmanager里面stopListening的时候做判断才用到,别的地方没看到过。感觉这里设计的有点多余,别的地方removeListener的时候又没有处理这块. 可能eventmanager和ext-base是不同人写的,呵呵。 你把这2行注释掉,就不会出现上面的内存问题了 |
|
返回顶楼 | |
发表时间:2008-03-18
引用 觉的还是这2行的问题
Java代码 复制代码 1. fn._handlers = fn._handlers || []; 2. fn._handlers.push([Ext.id(el), ename, h]); fn._handlers = fn._handlers || []; fn._handlers.push([Ext.id(el), ename, h]); 这里的_handlers只在Eventmanager里面stopListening的时候做判断才用到,别的地方没看到过。感觉这里设计的有点多余,别的地方removeListener的时候又没有处理这块. 可能eventmanager和ext-base是不同人写的,呵呵。 你把这2行注释掉,就不会出现上面的内存问题了 注释掉恐怕不行,因为实际有些地方使用了el.un(...,fn)的方式停止监听,在ext的论坛上搜索_handlers destory,可以找到一篇11份的帖子提到这个问题,ext的开发人员在一些相关的回答中隐约说了要解决这个问题。假如ext本身保证了以非global function作为监听器,或者我们小心点去避免这个问题,呵呵。 |
|
返回顶楼 | |
发表时间:2008-03-19
我的意思是为了证明问题原因注释掉测试一下。
还是等ext自己去解决,或者自己小心使用了。呵呵 |
|
返回顶楼 | |
发表时间:2008-03-19
找到解决办法了 一会发新帖
======================= 收回上面的话 虽然可以解决 但是会打乱ext的依赖 再想想先 |
|
返回顶楼 | |
发表时间:2008-03-19
呵呵,等着楼主的解决方法.自己目前还没有这个能力去做这个事情.
|
|
返回顶楼 | |