我的模块加载系统 v15

本次改进是沿着上次的思路，让定义模块名尽量的短，然后只要保证请求时路径正确，那么它就会内部非常智能修正这个模块的名字，自动加上路径。至于这些模块叫什么名字，有什么属性，可以查看框架的系统属性@modules。尽管v14做得的改进非常人性化，但毕竟初次试水，还有许多不足与BUGs。v15就是在这方面进行了改良，原先模块名的修正逻辑是写define方法中，现在转移到一个叫innerDefine的方法中，并让其在临时生成的iframe沙箱环境中执行，确保没有改错。另外，v15，还对许多内部函数与私有属性进行更名，让其更加秀气易懂。下面是改进详情：

• 用于保存需要处理的模块名列表的内部数组 names 改名为 tokens（令牌集）。
• 相对应，原来叫name或_name的变量与属性名也改名为 token(令牌)。
• 用于收集各个模块的返回值的内部对象 rets 改名为 transfer(中转器)。
• 用于保存每个模块的信息的对象map 更名 mapper。
• 用于转换iframe执行环境中生成的函数的内部函数 safeEval 改名为assemble（装配）。assemble比原来的safeEval 职责更加单一，收集依赖列表对应模块的返回值，传入目标模块中执行。
• 添加innerDefine 方法，它用于处理iframe沙箱环境中通过script节点加载回来的$.define，它也相当于一个中转器，但会将其第一个参数（模块名）修正一下，加上相对路径，并且将callback重新解析为父窗口的函数实例（这相当于原来safeEval的工作），最后才交给父窗口的命名空间对象的define方法去处理。
• 用于创建沙箱环境加载子模块的内部方法 loadModule 更名为 load， 并且在其内部字符串拼接部分进行大重构。
• 用于判定某一模块的依赖列表是否都加载成功的内部函数_resolveCallbacks，更名为_checkDeps。
• 另外，_checkFail方法也做了些许改良，确保命名空间改名后报“找不到对象”错误。

v15借助于innerDefine来校正模块名的思路，其实已经很好地解决了业界AMD的匿名模块难题。但mass Framework作为一个大规模开发的框架，还要考虑一下JS文件合并的情况。因此$.define的第一个参数——模块名还是保留下来。这也有出于向前兼容的考虑。

最后举个例子说明v14与v15做了什么魔术吧。在KISSY中定义一个位于另一个文件夹的JS模块，需要指定路径，来防止重名。如aaa文件夹下有个test模块，bbb文件夹下也有一个test模块。定义时是这样进行区分的：

KISSY.add('aaa/test', function () {

//....aaa/test略

});

KISSY.add('bbb/test', function () {

//....bbb/test略

});

KISSY.use('aaa/test', function () {

//....略

});

KISSY.use('bbb/test', function () {

//....略

});

而从mass Framework的v14开始，则可以省略路径，如果不考虑服务器合并JS文件的情况，模块名叫什么也没所谓，因为请求模块时的路径就会被innerDefine改为其“正确”的模块名！它这种特性非常有利于我们在项目对目录结构的重构。

$.define('test', function () {

//....aaa/test略

});

$.define('test', function () {

//....bbb/test略

});

$.require("aaa/test",function(){

//....略

});

$.require("bbb/test",function(){

//....略

});

源码地址

相关链接:

我的模块加载系统 v14

我的模块加载系统 v13

我的模块加载系统 v12

我的模块加载系统 v11

我的模块加载系统 v10

我的模块加载系统 v9

我的模块加载系统 v8

我的模块加载系统 v7

我的模块加载系统 v6

我的模块加载系统 v5

我的模块加载系统 v4

我的模块加载系统 v3