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

我这边有一个页面有一个TabPanel，共包括6个Tab页，39个Field分布在tab页中，其中包括两个表格；并且有4个弹出window。

简单表单的销毁比较容易，直接调用formPanel的销毁方法或者viewPort的，由于EXT2的组件树架构，会逐层的自动调用destroy方法。

复杂界面有些Field由于没有加入这棵树（而直接renderTo到div或者别的dom节点里），所以创建了资源的同时，要记得在formPanel组件的beforedestroy方法中进行销毁就可以有效的缓解泄漏的问题。

使用IFrame的话，文件也不是缓存的。

A页面加载的ext-all和ext.css文件，只提供A布面使用，如果IFrame重新加载到B页面，那B页面还是会重新加载一次ext-all与ext-css,不可能使用A页面的缓存。只有当再次IFrame加载A页面的时候，A页面才有可能使用己经存在的缓存。如果有十个页面，使用iFrame方法加载，那ext-all与ext-css至少要各被加载十次。

客气！
我当前的方案是lazyModule＋autoLoad
至于OO in JS，我整理的资料不是很多，－－EXT OO在1.x时大概是照搬YUI的，到了2.0某些组件取消了构造器而是重写initComponent()
edit:修正单词错误

autoLoad? 你是说结合使用HTML片段吗？
我们现在有部分模块的Form区是通过载入HTML片段生成的，在用户打开Tab Form的相应标签页时才将其中的组件转化成Ext组件．效果会比直接生成Ext组件好很多，只是还是不能完全解决问题

是的 autoLoad －》HTML片段
配合模块化的设计lazyModule使用。
甚至可以利用ext组件render on Demand进行组件的设计（服务器返回JSON的组件配置项）

经过一夜一天的查找，毫无结果。
首先：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内存，大家遇到相同的问题吗？

我也最近做了一个EXT的项目，个人认为： Ext 性能提升还有很大的潜力，只要你愿意花功夫。
比如，你使用Struts2.0的化，在struts.xml定义action时通过execludeProperty把一些不需要的列出来的属性把它过滤掉，这样在存在ManyToMany或oneToMany时就快了很多。
还有就是对一些不需要范围JSON对象（如update某些类的信息。删除某个类）的，在struts.xml定义action时，使用<result type="httpheader"/>可以避免一些内存溢出，因为很多的内存溢出是由于在读取数据发生死循环，而这些读数据操作很多是不需要的，

pheyrol所说的性能提升根本是另外一回事吧

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

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

这个帖子里有“高手”二字，不知道是怎么发上去的。记得我当初发贴，MS不能有这个词。——题外话，打扰了，毙了我吧......

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

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

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