Ext 2.0 for JSVM

这里讨论 Ext 的气氛很热烈， 最近手上的项目基本上都是基于Ext开发的，Ext2.0表现得几乎完美（除了性能方面），前面有帖子在讨论代码组织方面的问题，我把jsvm 组织 ext 的示例与大家分享和讨论。

下载：
http://demo.jsvm.org/ext2/ext-2.0-beta1-jsvm2.tar.gz

网上的例子：
http://demo.jsvm.org/ext2/ext-2.0-beta1-jsvm2/examples/

上面的例子其实都是ext自带的，不过没有引用ext-all.js，而是通过jsvm2 & smartloader 来实现按需加载。（smartloader 是jsvm2.06之后的一个模块，能自动将页面需要的class.js文件打包加载，代码之间的依赖和加载不需要人工维护）

看来 wch3116 也在关注 Ext :-)

JSVM2.06 相比之前精良了不少，JSVM 一向在代码组织规范方面做的不错，希望能给日益庞大复杂的 Ext 代码管理方面提供一些思路和启发～

另外发现 ExtJS 论坛上也有相关讨论：
http://extjs.com/forum/showthread.php?t=15939

不错, 看了一下源码, 那些每个class上面的import都是作者一点点加上去的么? 还是有什么简单的办法, 感觉要是一点点加上去的话,  那可不是一般的强呀

$import("Ext.dd.DDM");
$import("Ext.dd.DropTarget");
$import("Ext.dd.Registry");

/*
* Ext JS Library 2.0 Beta 1
* Copyright(c) 2006-2007, Ext JS, LLC.
* licensing@extjs.com
*
* http://extjs.com/license
*/


我看到Ext里面的文件都被加上了$import语句，这些是自动生成的还是手工维护的？如果自动生成，是否有工具实现，能共享就太好了。
另外我看了下smartloader是需要后台动态页面辅助，因为我自己也有类似实现，既然有后台辅助，提个小建议：多个$import在可以后台合并文件，减少多次交互，可使用类似$import(A,B,C,D)语法

解析Ext模块之间依赖关系的工具非常简陋，几乎没有共享出来的价值，呵呵。
大概原理是：通过正则表达式匹配出当前模块的代码中引用了哪些其它 Ext 模块的名称，然后在文件头部生成 $import 语句。
但是存在一些地方是需要手工调整。因为模块之间文件头部“静态”import 不能形成回环，循环import会造成 jsvm engine 的“死锁”。所以必须将一些造成回环的依赖链打断，调整为运行时动态的import。
启用过smartloader的页面，不会存在多次xhr交互的情况。当然这并不否定import支持多个动态参数是一个好的办法。

再谈 js 代码的加载问题

我们在开发一个 rich javascript 应用时，一般会遇到两件事情：
1. 代码应该按功能、模块或其它合理粒度方式切分到多个文件单元中，以便于管理维护和重用。
2. 系统运行时，应该按需加载所要执行的模块代码。因为将程序所有可能要用到的模块都事先全部加载进来听起来并不是一个好主意。

由于 js 代码因为设计上的需要被切分成多个文件，XMLHttpRequest 同步操作造成浏览器阻塞，如果网络不畅，这个过程时间长的话，浏览器的现象是假死（没有响应了）
传统的 <script> 标签方式加载多个 js 文件显然没有出现上面的问题，于是异步加载方案又被重新考虑进来。

其实在比较早（大概是2004年）的一次讨论中，有位网友提到了类似的问题，他提出了一个“异步加载”的方案。我们对此也做了不短时间的讨论。
但我一直坚持以为解决问题的方向不应该是“同步”和“异步”之间的选择问题。

“异步” 不仅打乱了开发人员的一般习惯思维方式，同时也改变了程序顺序加载执行最朴素的规律。
对于模块之间的静态依赖，或者程序对模块的静态需求，采用预加载的方式，然后通过事件侦听或者回调程序入口来继续加载后的的程序执行尚且可以。
但这些依赖或者需求是程序运行时动态决定的，而采用异步的方式肯定造成程序分支增多，增加了系统的复杂性。

而这一切就是为了解决浏览器同步加载多个文件时而造成的“假死”？
浏览器假死不是“同步”这个模式（概念）本身的错误。而是现有的环境（条件）造成的。
试想，如果仍然是同步阻塞，但没有造成浏览器假死是不是也能接受？
所以，我觉得可以通过其它方式来解决这个问题。

本地浏览模式或者网络相当顺畅的情况下，我们几乎不用太担心浏览器因为这种原因而造成的假死。
如果能为页面为单位，记录每个页面所需要的模块（代码），当下一次程序被运行时能提前将这些代码通过非阻塞的方式预加载到缓存（内存）中，
之后的代码加载都在内存中进行，虽然还是同步方式，但没有网络IO的操作，问题是不是解决了？

jsvm 2.06 之后的 smartloader 模块（扩展）就是基于这个原理工作的。
开发人员依然只需考虑设计层面的问题，而不必去关心过多加载次数造成的麻烦。

但对于使用EXT构建类似One Application One Page应用，显然这种预加载就不怎么适用了，往往需求反而变成尽量延缓加载，在模块启动时（用户点了菜单项或快捷方式后）才会去再栽js代码运行。

此外有个疑问，我没仔细研究过有smartloader的代码，万兄是如何在页面加载前就下载关联js代码并缓存的？

(1)因为page未加载，js运行context未建立，如果就能预下载到jsvm里，那么jsvm跑在什么环境中？必须存在一个包含jsvm运行环境的页面，然后多页面能共享jsvm？
(2)用户关闭浏览器后再次打开浏览同一页面，这个时候能做的js缓存好象只有服务器缓存吧？这样还是无法解决同步阻塞的问题。

其实万老大整理的Ext包依赖关系非常好用，哪怕不使用jsvm但我相信只要实现动态加载机制的系统都能用，只要也使用$import函数名即可使用，放在我这里刚好适用，所以我有个建议，如果大家对采用这种机制的js文件的目录组织方式，命名方式，import接口有一定的约定，即使不强求大家采用某种动态载入框架，那么将来可能互相之间能共享的代码也会更多。
  比如我的情况，由于js文件的管理使用了servlet，并有些别的权限管理考虑与整个系统设计揉在了一起，所以不太可能直接采用jsvm或其他的方案，宁愿自己写一个轻量级的import方案。

如果大家在以下几个方面能达成共识就可以做到：
（1）同步和异步import的函数定义
（2）js文件的目录组织和import包名的关系（比如目录层次即为包名，js文件名即为class名）
（3）依赖关系的处理(包文件、头文件、配置文件、直接在原js里写)

smartloader 模块的启用是可选的,对于OAOP的应用我个人觉得也同样适用，当然，如果倾向延缓加载，或者其它更“可控”的加载方式，可以通过配置classpath决定哪些lib预加载，而其余的模块根据运行时动态加载。如何实现最优配置由设计者自己决定。
1. web server 启动后，page 第一次被浏览时 smartloader 会记录哪些代码是当前page所需要的，同时在服务端建立缓存。 jsvm 客户端代码的缓存是 navigator 对象级的, 共享navigator对象的页面之间都可以自动共享缓存，例如：iframe,frameset，opener 之间的所有页面。
2.smartloader批量预加载，和classpath中的lib加载都是<script>标签方式，不会导致浏览器因阻塞假死。另外，客户端的304缓存也是好用的。
可以通过httpwatch之类的工具查看一下http交互记录，就十分清楚了

补充：jsvm 对代码的加载是分两级的，1.加载code,2.执行code（基于eval的封装），这两级每层都有自己的缓存机制。另外，smartloader 也可以在服务端解析code从而分析出依赖关系，将所静态依赖的class.js文件一并加载，从而解决了服务器启动后page被第一次访问时的缓存的问题，而我觉得这个目前并不是很重要，留到日后升级版本中去实现。

没错！如今js framework很多，还有很多人都在设计自己的framework，如果这些framework之间能达成协议，采用相同规范的接口，那么基于这个规范，一样可以实现跨framework/container的js开发。