2008-03-10

有没有用EXT做过大型企业级应用的高手？

目前我们的项目前端使用的是EXT2.0结合DWR, 并且采用完全OPOA的结构,即一个模块对应一个独立的JS文件,在用户访问时才动态载入并生成Tab页面. 这种结构在应付项目初期的简单模块时还是游刃有余的, 但是随着项目的发展, 页面设计越来越过于复杂, 有些页面甚至需要用到一百多个Field组件，于是现在各种问题也凸现了出来，尤其是浏览器的内存泄露。我们目前暂时想到了两种解决方案：

一是采用“隐藏”的方式替代“关闭”，即模块页面打开后再关闭时只对其做隐藏，再次打开时只需做页面数据的刷新， 因此不会占用新的内存和页面初始化时间。虽然项目庞大，但是实际使用时使用者拥有的模块权限不会很多，因此是不会出现打开所有模块将内存消耗殆尽的情况的。

二是舍弃OPOA的结构，在Tab页中嵌入IFRAME，将每个模块独立成单个页面。目前发现这种方法在处理内存泄露问题上的效果是比较好的，但是由于每个页面都必须重新引入EXT库的原因，单个模块占用的内存较之前增加了十多兆。而我们已经使用到了EXT的绝大部分功能，因此再对库文件做裁减意义已经不大。

不知道各位高手有没有更好的建议，烦请不吝赐教。
评论
znjq 2008-05-23
ext的内存泄露才是最严重的问题！
代码本身就有很多问题，该在beforedestroy的在ondestroy里面，该释放的不释放，该destroy的组件不destroy，等等。。。
内存泄露不解决，什么单页面，动态加载,autoload都是白费力气！！
sp42 2008-05-23
yanshiyi 写道
sp42 写道
yanshiyi 写道
microboat 写道
把每个模块都封装成JS类，主页面动态加载，用哪个模块就加载哪个。我目前就是这么做的，真正的单页系统。

如果模块达到上百个，每个模块都很很多自己的函数，你又该怎么办？估计到时候js函数都有1m多了。


不要简单地套用ext组件。
可自己尝试着写一些复合组件，即在ext组件上再联合封装一下，
通过项目的实践，感觉还是有必要建立适应程序自身的“控件”（crud、分类等）




如果你的系统要用到ext80%的组件，你还想自己开发吗？或者你相信你开发的比人家的更好吗？
我现在的东西都是我自己写的，但是有严重的内存泄露问题，遗憾的是我不懂ext，也不懂其他的组件库，只能等自己学好了javascript再说了。还好我们不用太多的富客户组件。

不是太明白你的意思。
其实不一定要全部都用ext，可结合自己的代码一步扩展。
kin_me 2008-05-23
请问谁用ext来做国报表啊
yanshiyi 2008-05-12
sp42 写道
yanshiyi 写道
microboat 写道
把每个模块都封装成JS类，主页面动态加载，用哪个模块就加载哪个。我目前就是这么做的，真正的单页系统。

如果模块达到上百个，每个模块都很很多自己的函数，你又该怎么办？估计到时候js函数都有1m多了。


不要简单地套用ext组件。
可自己尝试着写一些复合组件，即在ext组件上再联合封装一下，
通过项目的实践，感觉还是有必要建立适应程序自身的“控件”（crud、分类等）




如果你的系统要用到ext80%的组件，你还想自己开发吗？或者你相信你开发的比人家的更好吗？
我现在的东西都是我自己写的，但是有严重的内存泄露问题，遗憾的是我不懂ext，也不懂其他的组件库，只能等自己学好了javascript再说了。还好我们不用太多的富客户组件。
sp42 2008-05-11
yanshiyi 写道
microboat 写道
把每个模块都封装成JS类，主页面动态加载，用哪个模块就加载哪个。我目前就是这么做的，真正的单页系统。

如果模块达到上百个，每个模块都很很多自己的函数，你又该怎么办？估计到时候js函数都有1m多了。


不要简单地套用ext组件。
可自己尝试着写一些复合组件，即在ext组件上再联合封装一下，
通过项目的实践，感觉还是有必要建立适应程序自身的“控件”（crud、分类等）

csf177 2008-05-10
Ext在内存泄漏上已经下了很多工夫了
很遗憾还有这么多问题 只能等它自己解决了
yanshiyi 2008-05-09
microboat 写道
把每个模块都封装成JS类，主页面动态加载，用哪个模块就加载哪个。我目前就是这么做的，真正的单页系统。

如果模块达到上百个，每个模块都很很多自己的函数，你又该怎么办？估计到时候js函数都有1m多了。
fangzhouxing 2008-04-08
microboat,能详细描述一下你的开发方法吗？
microboat 2008-04-07
把每个模块都封装成JS类，主页面动态加载，用哪个模块就加载哪个。我目前就是这么做的，真正的单页系统。
fangzhouxing 2008-04-07
用ExtJS开发大型企业级应用的最佳实践，可以参考：
1）http://extjs.com/forum/showthread.php?t=26728

2）http://extjs.com/blog/2008/03/31/implementation-spotlight-jama-contour/
jiakechong 2008-04-06
有人用google的gwt吗,好象界面效果跟ext差不多把
bevin_b 2008-03-17
没有什么恭与不恭，我承认我就是菜鸟

只是希望高手在指点大家的时候，能先认真看看别人说的是什么，甚至能再浪费一点宝贵的时间自己去试一试真的有没有这种问题存在．就像被你引用的几句话，和你所说的好象没有什么联系吧
dboylx 2008-03-17
bevin_b 写道
dboylx 写道
bevin_b 写道
pheyrol所说的性能提升根本是另外一回事吧

另外EXT的部分组件在销毁时存在DOM节点删除不彻底的bug，以前就注意到了，这个问题在2.0版本中仍然存在，其官方论坛的说法是会在下一个版本中系统解决．

现在最为头疼的还是内存泄露的问题．就以其自身的API文档为例,如果你打开了大量的标签页然后全部关闭,你会发现浏览器的内存根本没有减少,至少在IE6和FF2中是这样的. API文档里的标签页只是简单的文本页面, 即使你打开再多的页面, 也不会耗用多少的内存. 可是在我们这样的系统中, 一个复杂的模块页面在不做任何数据库读取操作的情况下, 单只是页面初始化之后所占用的内存就达到了十多M, 在反复的打开关闭之后, 系统的性能可想而知. 但是这样的问题, 从其官方论坛来看目前还是没有得到足够的重视, 有人说建议更换浏览器, 不要用IE6了. 是的, IE是内存泄露之王, 可是你的客户会明白这些吗?



一个FORM, 三十个字段, 如果处理不好, 很可能一个更新的操作就会带来几M的内存泄露. 如果是个熟练的录入人员, 半小时就有可能开销一个G的客户机内存.

很正常, 大胖不是说过么, EXT是非常优秀的架构. 但优秀的架构也需要有相应的能力与团队去驾驭它.

并不是官方不重视, 如果您足够关心, 可以看到JACK与Animal在去年中经常讨论与解决客户的类似问题. 在2.0时甚至在Composite设计里加入了Destroy内存回收的调用 (1.x Animal建议自己扩展基础组件), 但这也是在一个工作区内JS架构设计所能做的极限. 如果您使用了iFrame(Jack也建议使用它), 那么您的内存回收就要自己想办法了. 官方有很优秀的单例实现, 与CACHE的解决方法归避客户端的内存泄露. www.extjs.com



你所说的这些，即使是一个刚刚接触Ext的人都会明白

即使自认为是高手，也请仔细看明白了问题再发表意见好吗？


言语不恭，向您道歉~~~
bevin_b 2008-03-17
dboylx 写道
bevin_b 写道
pheyrol所说的性能提升根本是另外一回事吧

另外EXT的部分组件在销毁时存在DOM节点删除不彻底的bug，以前就注意到了，这个问题在2.0版本中仍然存在，其官方论坛的说法是会在下一个版本中系统解决．

现在最为头疼的还是内存泄露的问题．就以其自身的API文档为例,如果你打开了大量的标签页然后全部关闭,你会发现浏览器的内存根本没有减少,至少在IE6和FF2中是这样的. API文档里的标签页只是简单的文本页面, 即使你打开再多的页面, 也不会耗用多少的内存. 可是在我们这样的系统中, 一个复杂的模块页面在不做任何数据库读取操作的情况下, 单只是页面初始化之后所占用的内存就达到了十多M, 在反复的打开关闭之后, 系统的性能可想而知. 但是这样的问题, 从其官方论坛来看目前还是没有得到足够的重视, 有人说建议更换浏览器, 不要用IE6了. 是的, IE是内存泄露之王, 可是你的客户会明白这些吗?



一个FORM, 三十个字段, 如果处理不好, 很可能一个更新的操作就会带来几M的内存泄露. 如果是个熟练的录入人员, 半小时就有可能开销一个G的客户机内存.

很正常, 大胖不是说过么, EXT是非常优秀的架构. 但优秀的架构也需要有相应的能力与团队去驾驭它.

并不是官方不重视, 如果您足够关心, 可以看到JACK与Animal在去年中经常讨论与解决客户的类似问题. 在2.0时甚至在Composite设计里加入了Destroy内存回收的调用 (1.x Animal建议自己扩展基础组件), 但这也是在一个工作区内JS架构设计所能做的极限. 如果您使用了iFrame(Jack也建议使用它), 那么您的内存回收就要自己想办法了. 官方有很优秀的单例实现, 与CACHE的解决方法归避客户端的内存泄露. www.extjs.com



你所说的这些，即使是一个刚刚接触Ext的人都会明白

即使自认为是高手，也请仔细看明白了问题再发表意见好吗？
1314520ln 2008-03-17
为什么非要用ext作开发呢?
dboylx 2008-03-14
bevin_b 写道
pheyrol所说的性能提升根本是另外一回事吧

另外EXT的部分组件在销毁时存在DOM节点删除不彻底的bug，以前就注意到了，这个问题在2.0版本中仍然存在，其官方论坛的说法是会在下一个版本中系统解决．

现在最为头疼的还是内存泄露的问题．就以其自身的API文档为例,如果你打开了大量的标签页然后全部关闭,你会发现浏览器的内存根本没有减少,至少在IE6和FF2中是这样的. API文档里的标签页只是简单的文本页面, 即使你打开再多的页面, 也不会耗用多少的内存. 可是在我们这样的系统中, 一个复杂的模块页面在不做任何数据库读取操作的情况下, 单只是页面初始化之后所占用的内存就达到了十多M, 在反复的打开关闭之后, 系统的性能可想而知. 但是这样的问题, 从其官方论坛来看目前还是没有得到足够的重视, 有人说建议更换浏览器, 不要用IE6了. 是的, IE是内存泄露之王, 可是你的客户会明白这些吗?



一个FORM, 三十个字段, 如果处理不好, 很可能一个更新的操作就会带来几M的内存泄露. 如果是个熟练的录入人员, 半小时就有可能开销一个G的客户机内存.

很正常, 大胖不是说过么, EXT是非常优秀的架构. 但优秀的架构也需要有相应的能力与团队去驾驭它.

并不是官方不重视, 如果您足够关心, 可以看到JACK与Animal在去年中经常讨论与解决客户的类似问题. 在2.0时甚至在Composite设计里加入了Destroy内存回收的调用 (1.x Animal建议自己扩展基础组件), 但这也是在一个工作区内JS架构设计所能做的极限. 如果您使用了iFrame(Jack也建议使用它), 那么您的内存回收就要自己想办法了. 官方有很优秀的单例实现, 与CACHE的解决方法归避客户端的内存泄露. www.extjs.com
zenny 2008-03-14
这个帖子里有“高手”二字，不知道是怎么发上去的。记得我当初发贴，MS不能有这个词。——题外话，打扰了，毙了我吧......
bevin_b 2008-03-14
pheyrol所说的性能提升根本是另外一回事吧

另外EXT的部分组件在销毁时存在DOM节点删除不彻底的bug，以前就注意到了，这个问题在2.0版本中仍然存在，其官方论坛的说法是会在下一个版本中系统解决．

现在最为头疼的还是内存泄露的问题．就以其自身的API文档为例,如果你打开了大量的标签页然后全部关闭,你会发现浏览器的内存根本没有减少,至少在IE6和FF2中是这样的. API文档里的标签页只是简单的文本页面, 即使你打开再多的页面, 也不会耗用多少的内存. 可是在我们这样的系统中, 一个复杂的模块页面在不做任何数据库读取操作的情况下, 单只是页面初始化之后所占用的内存就达到了十多M, 在反复的打开关闭之后, 系统的性能可想而知. 但是这样的问题, 从其官方论坛来看目前还是没有得到足够的重视, 有人说建议更换浏览器, 不要用IE6了. 是的, IE是内存泄露之王, 可是你的客户会明白这些吗?
pheyrol 2008-03-13
我也最近做了一个EXT的项目，个人认为： Ext 性能提升还有很大的潜力，只要你愿意花功夫。
比如，你使用Struts2.0的化，在struts.xml定义action时通过execludeProperty把一些不需要的列出来的属性把它过滤掉，这样在存在ManyToMany或oneToMany时就快了很多。
还有就是对一些不需要范围JSON对象（如update某些类的信息。删除某个类）的，在struts.xml定义action时，使用<result type="httpheader"/>可以避免一些内存溢出，因为很多的内存溢出是由于在读取数据发生死循环，而这些读数据操作很多是不需要的，
nihongye 2008-03-13
经过一夜一天的查找，毫无结果。
首先：http://www.softwareverify.com/javascript/memory/index.html
这个工具，能检测firefox的内存使用情况,试用版也挺好用，不过我再它上面花了一个晚上，还是没解决问题。
另外还有一个地址：http://developer.mozilla.org/en/docs/Debugging_memory_leaks
可以深入研究这个问题。
我的测试例子是这样的：
总的页面由一个BorderLayout布局控制，其Center Region将加载一个Html片断，该Html片断使用BorderLayout建立一个列表的管理界面，点击导航菜单后触发该区域的更新（先移除旧的组件，再加入新的）。
通过重新控制Ext带的垃圾回收，确认了Ext.Element的缓存中的孤子元素会定时的清除;通过firebug，确认每次点击后页面中残留有SplitBar产生的Tag。
firefox2,3,opera都测试过，内存涨，但不会导致应用缓慢，firefox2上平均每次点击增长500k内存，大家遇到相同的问题吗？
发表评论

提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则

您还没有登录，请登录后发表评论

bevin_b
搜索本博客
博客分类
最近加入圈子
最新评论