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

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

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

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

不知道各位高手有没有更好的建议，烦请不吝赐教。

每个页面重复用EXT库有什么问题吗？js文件本身是缓存的呀。只要你所有页面引用的js的地址是一致的。这个不会带来速度的影响吧。

另外我的做法是。不是通过一个Tab处理所有的页面，也不是通过一个模块就是一个页面。通常应用是可以分隔的，也就是把一个系统划分多个组成部分（模块），然后每个模块是由一个页面完成。不是一个Page就是一个模块.

缓存的只是文件本身，真正占内存的是EXT本身的对象,所有的组件定义都会占用内存的．你在一个空的页面里面单引入EXT库，你就会发现页面内存会立即增加10M多.

模块分割是设计人员的事，我们没法干涉，已经多次反映过这个问题，至今没有结果．如果当初设计人员能够和架构师充分沟通，互相理解，也就不会有今天的问题了

IFrame是性能大忌，可避免尽量避免
既然说是“大型”企业级AJAX应用，不能不谈OO in JS

这个问题该如何解决呢？

那请教一下sp42，你有没有更好的建议呢?

我们的应用也是opoa的，用的是ext1.1。
在linux、1g内存、firefox2.0.11、的机器上跑，只见内存彪升,但是firefox的内存泄漏检测插件没有报告泄漏现象;在windowsxp 256m内存(有100m的可用内存)，firefox2.0.12上保持在50m的内存占用。
这现象或者是firefox本身的内存管理的特性，并不是泄漏。另外注意destroy ComboBox，因为combo的layer是建立在body下，感觉destroy掉好些吧。
另外，将应用所有模块的js使用jsa打包并压缩成一个文件，再用gzip(apache deflate)压缩，385k经过两次压缩后，30k，相当好。
应用的地址是http://www.abestek.com，进入演示...

楼上的，你的产品演示在哪儿呢，很想看一下

我个人是从EXT2.0Alpha版发布才接触这个框架的，所以不大了解EXT1.1，destroy动作是组件销毁时自动完成的，是不需要手工调用的啊，但是模块关闭时内存并没有释放．我们的每个模块都是一个Panel对象

另外文件压缩是项目后期的事情，目前在局域网内开发暂时不考虑网络的影响

演示在上面给出的地址里啊。我现在正用selenium，用脚本重复的动作，看几百个操作下来，ext的情况如何;你也可以试试。可惜ext1.1不是组件树,羡慕ext2。

看过你们的demo了，想知道在你们实际的产品里边，会出现有一百多个Field的Tab Form吗？如果有的话，你们是怎么解决的啊