JSI的导入指令参数顺序调整意见征询

改动

  2.0方式：

$import(path,callbackOrLazyLoad,target)

调整成(将target参数提前)

/**
 * @param <string> path (package:Object|package.Object|package.*| scriptPath)
 * @param < Object> target 可选参数，指定导入容器。
 *                    当该参数为有效对象时(instanceof Object && not instanceof Function)，导入的元素将赋值成其属性；
 *                    当该参数未指定时 (arguments.length==1)， target为全局变量容器,这种情况等价于直接声明的全局变量。
 * @param <boolean|Function> col callbackOrLazyLoad 可选参数,默认为null。
 *                    如果其值为函数，表示异步导入模式；
 *                    如果其值为真，表示延迟同步导入模式，否则为即时同步导入（默认如此）。
 */
$import(path,target,col)

理由：

延迟装载和异步装载并不常用。
而target紧跟path似乎更合逻辑。

 

不妥之处：

对于target的处理：
以前的办法：当制定null时，是不会将导入的对象拉出来的，只有没有指定target的时候，才会使用global(window)对象（arguments.length<=2）。
而现在，一但指定了callbackOrLazyLoad，target就必须指定了，这个时候，如何去处理还没想好。

 

JSI开发现状：

http://xidea.cvs.sourceforge.net/xidea/JSI2/web/source/boot-core.js?view=markup
目前主要的发展方向是开发环境支持、简化内核。
一切向易用、简单、性能方向考虑；避免过渡设计。
2.0版，启动文件压缩后近30k

2.1彻底清理了一些不常用的功能，同时，将一些非必要的功能，作为可选项。
最小版本压缩后不到5k（未启用文本压缩）。

 

 

 

评论

34 楼 hax 2008-02-16  

jindw 写道

JSVM确实不错,国内算做的最早最大的了,我也比较喜欢他.
不过,我也认为这个东西过于复杂,增加了学习成本.
使用正则将类java语法翻译成真正脚本,这个过程也时非常复杂的,性能可靠性上都有点担心,研究还不够深入,也许是多余的担心吧,呵呵.

有机会的话开个座谈会，找老万来给我们剖析一下jsvm2的设计。然后你也可以给我们剖析一下jsi2的设计。

33 楼 jindw 2008-02-16  

JSVM确实不错,国内算做的最早最大的了,我也比较喜欢他.
不过,我也认为这个东西过于复杂,增加了学习成本.
使用正则将类java语法翻译成真正脚本,这个过程也时非常复杂的,性能可靠性上都有点担心,研究还不够深入,也许是多余的担心吧,呵呵.

32 楼 kebo 2008-02-16  

jindw 写道

呵呵,用惯了eclipse的重构支持,再编辑js文件,很多东西总是那么不方便,所有就想自己写写.

另外一个因素:我发现JSI的某些特性,对于IDE支持非常有利,而这些是其他通用脚本开发环境无法提供的,所有决定自己写写.



这种东西市场我也不看好,脚本基本都是用来做一些网站边边脚脚性的东西.代码量都非常少.
需要用JSI这样的脚本管理环境的情况还是非常少的,用户不多,自然就没有市场.

我们项目中60%代码是js。相反java代码倒是很少，有些控制直接就用js来做了，后台基本就是数据处理这块.迫切需要脚本管理环境。当时看了jsi和jsvm，最后选择了jsvm，呵呵。个人感觉支持环境不太需要ide工具。

31 楼 jindw 2008-02-15  

呵呵,用惯了eclipse的重构支持,再编辑js文件,很多东西总是那么不方便,所有就想自己写写.

另外一个因素:我发现JSI的某些特性,对于IDE支持非常有利,而这些是其他通用脚本开发环境无法提供的,所有决定自己写写.



这种东西市场我也不看好,脚本基本都是用来做一些网站边边脚脚性的东西.代码量都非常少.
需要用JSI这样的脚本管理环境的情况还是非常少的,用户不多,自然就没有市场.

30 楼 zhourenjian 2008-02-15  

jindw 写道

恩，确实，如果现在抽时间去集成extjs对于JSI的推广非常有利。

但是，可能是出于个人自私的一面吧。

一来，集成extjs对我个人技术来说，没有什么帮助。而且，我不懂ext，工作上也用不上这个，就算我集成了，我野没有时间去维护跟踪，这也是不负责的做法。

二来，我还是去发挥自己的长处。把IDE做好。虽然也如你所说，已经有人去做，但是没有人去做针对JSI的IDE。而JSI对于IDE来说，可以提供更好的语法提示，重构支持，就从这点，我可以做到比通用脚本编辑器功能更强大。我想，也是非常值得我一做的。

你要搞JSI的IDE？

我个人觉得没必要，没什么理由。:D

29 楼 jindw 2008-02-15  

其实也不叫依赖服务器端了.
是这样,发布的时候,我可以一次将全部脚本处理好,作为静态文件放置在服务段.
但是调试期间,为了方便,我就直接通过代理,即时处理这些脚本了.

另外,异步装载和同步装载需要的资源完全相同.
不需要对脚本做闭包处理.

28 楼 hax 2008-02-14  

果然是要依赖服务器端啊。而且从你说的来看，好像无论是script标签延迟加载，还是异步加载，都是要配合服务器端的？

27 楼 jindw 2008-02-14  

JSI的延迟装载和异步装载过程非常相似.

他们的实现是这样的:
1.计算出全部未装载的依赖,并将依赖加入缓存.
2.执行同步装载.

其实所有的三种装载方式,原理都是一样的,只不过非同步装载在真正装载前有个预处理.
而异步装载和延迟装载的区别也就在于预处理过程中如何缓存脚本.
异步装载就是直接xhr异步读取js文件,加入JSI的脚本缓存.
而延迟模式就略显麻烦了,如hax所言,他是通过打印一段引用脚本,脚本文件的内容就是用闭包封起来的源代码.

$JSI.addCacheScript("mypkg","hello.js",function(){eval(this.varText)/**
 * helllo world 函数
 */
function hello(){
    alert("hello world")
}
})

而这段脚本的生成,我们可以在脚本打包时自动生成.
如果在调试期间,我们不希望每次修改都去运行任务,我们可以用一个jsp代理或者一个servlet过滤器去做相关的文本处理,同时还可以确保转换后的脚本与源文件行数完全对应,这就是JSI对于调试友好实现的基本原理.

其中:eval(this.varText)这句时jsi里面比较关键的一点,他除了申明依赖之外,还构造了一个钩子函数.
能后外界就可以控制装载单元的内容了.如:注入装载后依赖.

26 楼 hax 2008-02-14  

jindw 写道

是的,若要良好的调试支持,就不能eval了.
可以用延迟装载的方式,和同步装载的区别是,导入指令和其他脚本必须写在不同的script标签里(延迟装载就是说,$import的对象需要在下一个script标签中才能生效),这样,没有异步回调那么麻烦,也不必忍受eval带来的调试困难.
算是鱼与熊掌各取一半吧.

还有，延迟装载，就要求该脚本文件要把自己的变量包在一个闭包中避免泄漏到global上去。这个包裹过程在有eval的情况下可以自动加上，在异步load的情况下已然被封到了onload函数里。但是对于延迟装载就必须手动加了吧（当然可以配合服务器端程序变成自动的）。

25 楼 hax 2008-02-14  

jindw 写道

是的,若要良好的调试支持,就不能eval了.
可以用延迟装载的方式,和同步装载的区别是,导入指令和其他脚本必须写在不同的script标签里(延迟装载就是说,$import的对象需要在下一个script标签中才能生效),这样,没有异步回调那么麻烦,也不必忍受eval带来的调试困难.
算是鱼与熊掌各取一半吧.

还是采用前面的假设，用户用到jsilib1和jsilib2，jsilib1依赖prototype，jsilib2依赖jquery。现在的问题倒不是用户如何import jsilib1和jsilib2，而是jsilib1、jsilib2如何import prototype和jquery。

延迟装载貌似只能针对最后的client code（即在页面中的代码），如果我延迟载入了jsilib1，那prototype到底是怎么载入的呢？是否取决于jsilib1的import语句？

还有，如果要发布一个基于jsi的类库，那么该类库在导入其他类库的时候，到底应该采用哪一种方式呢？难不成，每种方式都备一份？

24 楼 jindw 2008-02-14  

hax 写道

jindw 写道

仍外,关于调试器依赖的问题,我还是不能认同hax的观点.
靠日志解决不是好办法.对于前端脚本来说,日志其实是加入在代码中的垃圾.
到时候还是要清理(JSA新版本中加入了调试信息清理功能).而且添加删除日志也远没有设置断点来的轻松.
而模块做到很小,也不一定是好事.
如果,项目一开始,我们就做好正式发布时导出成单一脚本,完全脱离装载器的打算,那么这样做很好.
但是,如果我们想在运行时采用jsi/pies之类的系统,那么模块太小对性能来说也是一个小小的考验.

设断点，script单元就必须是基于文件的，而不能eval了。这样你好像只能使用异步加载（即带有函数参数的$import来控制导入的名称了）。鱼与熊掌可以兼得否？

编程模块小我觉得总是好事情。可以在正式发布时通过某种打包方式（除了导出单一脚本，也可以用其它方式，譬如我看到jsi的源代码最后有cachedScripts参数，应该就是可以用来干这个事情的吧）解决性能问题。

是的,若要良好的调试支持,就不能eval了.
可以用延迟装载的方式,和同步装载的区别是,导入指令和其他脚本必须写在不同的script标签里(延迟装载就是说,$import的对象需要在下一个script标签中才能生效),这样,没有异步回调那么麻烦,也不必忍受eval带来的调试困难.
算是鱼与熊掌各取一半吧.


关于模块最小化,我们想法基本一致,我也期望编程模块细分,细分的时候充分考虑一下运行时脚本管理的开销就是.
我上面反对过渡细分,只是因为曾经碰到过变态的细分要求.条件反射,呵呵.

23 楼 hax 2008-02-13  

jindw 写道

仍外,关于调试器依赖的问题,我还是不能认同hax的观点.
靠日志解决不是好办法.对于前端脚本来说,日志其实是加入在代码中的垃圾.
到时候还是要清理(JSA新版本中加入了调试信息清理功能).而且添加删除日志也远没有设置断点来的轻松.
而模块做到很小,也不一定是好事.
如果,项目一开始,我们就做好正式发布时导出成单一脚本,完全脱离装载器的打算,那么这样做很好.
但是,如果我们想在运行时采用jsi/pies之类的系统,那么模块太小对性能来说也是一个小小的考验.

设断点，script单元就必须是基于文件的，而不能eval了。这样你好像只能使用异步加载（即带有函数参数的$import来控制导入的名称了）。鱼与熊掌可以兼得否？

编程模块小我觉得总是好事情。可以在正式发布时通过某种打包方式（除了导出单一脚本，也可以用其它方式，譬如我看到jsi的源代码最后有cachedScripts参数，应该就是可以用来干这个事情的吧）解决性能问题。

22 楼 hax 2008-02-13  

jindw 写道

JSI中依赖的处理和导入的行为是不同的.
JSI每个装载单元都有独立的上下文,他们的依赖也不会相互影响,也不会受全局变量的影响.
所以,hax上述的担心是没有的(如果是我理解的错误,还请hax耐心指出,^_^).

抱歉，偶过春节睡得太多睡糊涂了，这个是你原来就已经实现的特性，不过我看到你写的“当该参数未指定时，target为全局变量容器，等价于直接声明的全局变量”时，一时脑子岔了，以为你新版本的jsi为了异步导入和延迟导入的特性准备改成直接导入到global上了。

21 楼 jindw 2008-02-13  

nihongye 写道

我觉得import指令应该只包含所依赖的类名，如import("x.y.z")，至于"x.y.z"这个类在那个文件，通过另一个文件来指定，最好有一个默认的映射规则。
独立控制每个文件使用什么形式加载。
另外不用eval，用document.write script标签的形式，因为知道类和文件的映射关系，便可以检测相应的类是否存在来判定文件是否已经加载下来。

嗯,确实,JSI计算好依赖直接document.write出来,是一个简单的办法.比JSI现有的延迟装载实现简单,也不需要脚本转换.
完全没有装载器的介入,可能也更容易让人接受.
我也可能在后续版本中加入这种功能.

有利必有失,这样一来,完全没有装载器去隔离冲突,JSI的功能也就大大则扣.
这种装载方式,可以在开发调试时使用,运行时合并成单个脚本更合算.
其实,这种方式就是一个简单的运行时脚本合并功能.

20 楼 jindw 2008-02-13  

JSI中依赖的处理和导入的行为是不同的.
JSI每个装载单元都有独立的上下文,他们的依赖也不会相互影响,也不会受全局变量的影响.
所以,hax上述的担心是没有的(如果是我理解的错误,还请hax耐心指出,^_^).


例如,我在脚本C1中用到了jQuery,那么我申明

this.addScript("c1.js","C1",
                 "org.jquery.$");

能后,我在页面上直接:

$import("org.prototype.$");
$import("example.C1");

这里,两个$变量是不会相互影响的.
页面上调用的$是prototype的$,而c1.js里调用的$还是他的jQuery 的$.

关于prototype和jquery在JSI中共存的方式.
我以前专门写过一个例子:
http://jindw.iteye.com/admin/blogs/71280


仍外,关于调试器依赖的问题,我还是不能认同hax的观点.
靠日志解决不是好办法.对于前端脚本来说,日志其实是加入在代码中的垃圾.
到时候还是要清理(JSA新版本中加入了调试信息清理功能).而且添加删除日志也远没有设置断点来的轻松.
而模块做到很小,也不一定是好事.
如果,项目一开始,我们就做好正式发布时导出成单一脚本,完全脱离装载器的打算,那么这样做很好.
但是,如果我们想在运行时采用jsi/pies之类的系统,那么模块太小对性能来说也是一个小小的考验.

19 楼 nihongye 2008-02-13  

我觉得import指令应该只包含所依赖的类名，如import("x.y.z")，至于"x.y.z"这个类在那个文件，通过另一个文件来指定，最好有一个默认的映射规则。
独立控制每个文件使用什么形式加载。
另外不用eval，用document.write script标签的形式，因为知道类和文件的映射关系，便可以检测相应的类是否存在来判定文件是否已经加载下来。

18 楼 hax 2008-02-13  

kebo 写道

确实jsvm就是导入的脚本没法调试，压根看不到错误的行数。麻烦，只能用眼睛看。有机会试试你这个。

确实。这是个大麻烦。但是相比较 命名空间污染 的问题，我认为这两个问题不是在同一个层面上的。命名空间污染，是一个更加基本的编程问题。而调试定位问题，则是工具层面的问题。

总的来讲，如果类库整体是建筑在jsi/pies之类的系统上，则模块可以做到很小，而我们至少可以定位到源文件名，如果再配合良好的log，则调试定位的问题相对就降低了。

当然，有些同志养成了严重依赖调试器的习惯，这个就比较难办了。

17 楼 hax 2008-02-13  

jindw 写道

huhu，谢谢hax的分析。
不过，我们一些想法差别还是挺大的。

关于导入全局空间带来的污染问题。
我不那么看重。
JSI再降低命名污染的问题上，已经作了比较有效的工作。
例：
当我们import("com.xxx.C1")时。
可能，我们真正装载的是C1,C2,C3.....C100。而真正出来的变量只有C1
就是说：JSI已经吧这种污染降低了很大一步，我认为就没有必要再坐到更加及至了，那样有可能影响易用性。

再者，纵使我们真的要同时使用两个同名的不同包内的变量。
我们显示的指定target就是了，毕竟这种情况非常少见。

我觉得不能小看对全局命名空间的污染。我举一个例子。

假设有人写了一个 jsipkg1 的类库。在其中他
$import ("prototype") ，即他的类库依赖 Prototype 库。

有另一个人写了一个 jsipkg2 的类库。在其中他
$import ("jquery") ，即他的类库依赖 jQuery 库。

我们知道 prototype 的 $ 和 jquery 的 $ 是有冲突的。

现在问题就是，jsipkg3 能否同时使用 jsipkg1 和 jsipkg2。

假如$都是被导入到全局空间上，则就存在问题了。当然，也许jsi至少会给点异常信息。但是如果不能在不修改他们的源码的情况下使用，那就是一个问题。当然，我们可以修改jsipkg1和jsipkg2的源码，将其$import语句改为导出到一个容器上，但是这存在一个严重问题：

如果jsipkg1和jsipkg2原来是没有使用jsi的，那么原本他进入jsi，只需要加入依赖声明和import语句，工作量还是不大的，但是现在要修改大量源码了（所有用$的地方要改成 container.$），而且这个味道不好，因为破坏了使用者对于prototype/jquery库的使用习惯，也丧失了$短名字的好处。总之一句话，这里产生了jsi希望避免的侵入性。

再者，假如这是不可避免的，那么宁可在API上让大家默认导入到一个container上，这至少保证一个类库在写好之后不会造成全局命名空间污染，至于写jsipkg3的人，他如果爱用prototype，那他自己还可以强制的把prototype导到全局空间上（通过类似$import("prototype").to(window)之类的语法）。这个问题其实说明一点，如果我用jsi写了一个类库，C1,C2,C3.....C100，使用者只用C1，这个现在是可以办到了，但是现在的问题是，如何避免使用者在使用C1的时候，被迫接受全局空间上被加入了可能引起冲突的 $ 或其他类似的东西。

16 楼 kebo 2008-02-11  

确实jsvm就是导入的脚本没法调试，压根看不到错误的行数。麻烦，只能用眼睛看。有机会试试你这个。

15 楼 jindw 2008-02-11  

仍外，向后兼容，我现在基本不用考虑，除我之外，我还没见过谁在正式的项目中使用。
我可以放开手来修改。

身边的人，三言两语就可以吧这些改动说个清楚。