|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (4)
|
|
|---|---|
| 作者 | 正文 |
|
时间：2008-07-02
觉得还是用autoLoad实现比较好！
|
| 返回顶楼 | |
|
时间：2008-07-08
icewubin 写道 lims 写道 icewubin 写道 再举个例子便于楼主举一反三理解。
比如一个html中的图片指向的是其他网站的URL，你想想难道会是总的一次请求中会包含这些gif下在么？不会的，这个指向其他网站的URL一定是浏览器单独发请求的。 所以说对于gif、js、css，每个资源浏览器都是要单独发HTTP请求来下载资源的，但是某个资源（区分标准就是同一个资源URL，例如http://www.test.com/css/test.css，程序中的相对路径也是一样的，浏览器都会变成绝对路径发出请求的）如果已经下载过，就不会再此下载了。 还有个典型例子是你看一下，ext-2.0.2\resources\images\default\panel\tool-sprites.gif，ext实用css来限制这个图片显示的区域来复用这个图片资源，就是减少产生过多的gif资源HTTP请求，原本要下载1-44次（那副图包含了44个小图）数的图片，现在最多只下载一次，当然这里讨论的没有缓存，第一次需要下载图片的情况。据这个例子是为了进一步说明，这些资源是单独发URL请求的。 楼上的意思是我们根本没有必要再考滤ext-all.js的加载问题了，就算是用iframe，速度也应与one page one application的东西差不多了。确定是这样吗？ 那倒不是，我的意思是不用担心ext-all.js的重复下载过程。但是浏览器的重复加载和渲染这个js那是肯定不能避免的，此时效率高低取决于浏览器的算法，FF3的效率就比FF2高不少，目测即可看出。 所以楼主的做的工作还有有价值的，但是我突然想到，楼主的这种应用场景建议还是使用autourl，以及规范的id命名比较适合，既然用了iframe就应该耦合性保持在较低水平，否则还不如用ext自己的特性来做，效率和效果（有个动画加载效果）都有保证。 icewubin,你说了半天，ext-all.js这个大JS还得需要重新下载，那你以上的贴中所说的到底想表达一个啥东西呢？？ |
| 返回顶楼 | |
|
时间：2008-07-08
teclogid 写道 Ext有个问题有人知道怎么解决吗？
就是你弹出一个窗口（最简单的那种）。destroy掉。会多23dom节点。每次都会。（如果只是第一次会的话，可以理解，但是每次都会的话，说明destroy方法是有问题的） 不用奇怪,ext的众多bug中的一个.会有一些节点不释放. |
| 返回顶楼 | |
|
时间：2008-07-09
楼主想到的些许情况，ext官方和高手们早考虑了哈。
|
| 返回顶楼 | |
|
时间：2008-07-09
eyeshot 写道 icewubin 写道 lims 写道 icewubin 写道 再举个例子便于楼主举一反三理解。
比如一个html中的图片指向的是其他网站的URL，你想想难道会是总的一次请求中会包含这些gif下在么？不会的，这个指向其他网站的URL一定是浏览器单独发请求的。 所以说对于gif、js、css，每个资源浏览器都是要单独发HTTP请求来下载资源的，但是某个资源（区分标准就是同一个资源URL，例如http://www.test.com/css/test.css，程序中的相对路径也是一样的，浏览器都会变成绝对路径发出请求的）如果已经下载过，就不会再此下载了。 还有个典型例子是你看一下，ext-2.0.2\resources\images\default\panel\tool-sprites.gif，ext实用css来限制这个图片显示的区域来复用这个图片资源，就是减少产生过多的gif资源HTTP请求，原本要下载1-44次（那副图包含了44个小图）数的图片，现在最多只下载一次，当然这里讨论的没有缓存，第一次需要下载图片的情况。据这个例子是为了进一步说明，这些资源是单独发URL请求的。 楼上的意思是我们根本没有必要再考滤ext-all.js的加载问题了，就算是用iframe，速度也应与one page one application的东西差不多了。确定是这样吗？ 那倒不是，我的意思是不用担心ext-all.js的重复下载过程。但是浏览器的重复加载和渲染这个js那是肯定不能避免的，此时效率高低取决于浏览器的算法，FF3的效率就比FF2高不少，目测即可看出。 所以楼主的做的工作还有有价值的，但是我突然想到，楼主的这种应用场景建议还是使用autourl，以及规范的id命名比较适合，既然用了iframe就应该耦合性保持在较低水平，否则还不如用ext自己的特性来做，效率和效果（有个动画加载效果）都有保证。 icewubin,你说了半天，ext-all.js这个大JS还得需要重新下载，那你以上的贴中所说的到底想表达一个啥东西呢？？ 不需要，浏览器会命中缓存，这个我可以100%保证的，我测过很多次。 我的意思是，搂主的这方法，可以避免浏览器重复加载ext-all.js。加载和下载不一样，加载的JS可能来自于浏览器本地缓存。 |
| 返回顶楼 | |
|
时间：2008-07-09
搂主的这方法，可以避免浏览器重复加载ext-all.js
?/? 我可不这么认为 |
| 返回顶楼 | |
|
时间：2008-07-09
kimmking 写道 搂主的这方法，可以避免浏览器重复加载ext-all.js
?/? 我可不这么认为 未经验证，只是假定搂主做的实验是正确的话。 |
| 返回顶楼 | |
|
时间：2008-07-09
andrew.yulong 写道 觉得还是用autoLoad实现比较好！
唉，听了大家一番话，这两天正好把手头上的一个demo例子改成autoLoad的方式。 结论是放弃，问题非常多，bug也不少。 问题列表： 1.如果出现autoLoad中再套autoLoad，FF3下就会出现莫名其妙的错误，此时还会出现很要命的bug，当左边菜单栏收起来以后，嵌套中的页面居然就不能自适应一起缩放了。 2.div不能重复，虽然早就知道，但是实际操作还是个烦啊。 3.调试非常麻烦，碰到缓存问题，加了autoLoad参数nocache='true'，一样没用，url加时间后缀也没用，页面刷新也没用，一般只能关掉这个页面，重新打开新页面才有可能有用，已经排除tomcat缓存的作祟。也有可能是autoLoad嵌套的结果。要用鼠标右键查看加载的子页面的url找不到。如果是iframe，就没有这些问题。不知道大家对autoLoad的缓存问题是如何解决的，调试代码太麻烦了啊。 结论，如果autoLoad的页面是比较复杂的应用页面，绝对应该改成iframe，如果不信，大家可以自己试试。 简单页面得不出结论的，我也知道ext doc工作的好好的，但是做起实际复杂项目的时候就不是那么好玩了。 仔细想想，ext的这个autoload本质上来说是加载一个html片段，和iframe根本就是完全不一样的东西。 iframe下重复加载也没什么大不了了，实际用的时候，算上网络的延迟，这点时间可以不用计较的。 本来用传统方式URL跳转，不就是每次重新加载整个页面的JS么？也没见怎么个不方便啊。所以重复加载ext-all.js算不上什么大问题。 |
| 返回顶楼 | |
|
时间：2008-07-18
完全离题了，请问楼猪，你是怎么使用iframe的，而不需要再次加载ext-all.js....
|
| 返回顶楼 | |
|
时间：2008-07-18
lims 写道 说得那么轻松，做一些简单的CRUD，当然不用iframe了，做一个简单的什么新闻管理的，当然不用iframe了，但是，实际在一个庞大的系统中，你试试one page,one application。有时用delphi写都有点烦，不要说EXT了。其实，iframe不仅仅是用在tab中，dialog window中也要用呀。
庞大的系统使用ext，自作孽不可活。 |
| 返回顶楼 | |
