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（未启用文本压缩）。

 

 

 

评论

14 楼 jindw 2008-02-11  

确实，异步装载，很少用到，我以前的想法是，写一个非常简单的内核，不要异步。
能后，在一个扩展脚本中。在原同步$import的基础上，重写它，让他支持异步和延迟。
不过，后来发现，这样做起来，代码量猛增。因为，同步装载是很多内部函数无法在外部重用。最后还是退回了原来的方式，写在一起。

不过，还好，这次重写之后的内核，简单了很多很多，而且我在新版本的JSA上支持一种新的功能。feature选择。

就是说，我吧一些可选的功能，用if("<featureKey>"){...}包起来，这样我在导出的时候，可以灵活选取需要的功能，同样可以轻松剔除掉可能用不上的异步模式。


仍外，延迟装载在浏览器上还是非常有效的，而一旦支持了延迟装载，异步装载就是一个顺带的副产品了。


仍外，也许大家都被一些eval脚本的调试费劲脑汁了吧。
在开发期间。使用JSI2延迟装载模式，脚本就不是eval出来的了，对于调试就非常方便。
既有了自动装载，冲突隔离，有可以准确定位源文件的错误位置。

13 楼 jindw 2008-02-11  

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

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

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

12 楼 hax 2008-02-10  

<div class='quote_title'>jindw 写道</div><div class='quote_div'><p>刚才和<a href='http://zsp.iteye.com/' target='_blank'>小张</a>讨论了一下，更倾向于仍外一种方式</p><p> </p><pre name='code' class='java'>$import(path,colot,col)</pre> <p><br/><br/>即：</p><pre name='code' class='js'>$import(path,
            callbackOrLazyLoadOrTarget)
$import(path,
            target,
            callbackOrLazyLoad)</pre> <p> </p></div><p><br/><br/><br/>API的改动，你是否要保持向前兼容？</p><p> </p><p>我给点参考，pies旧版本的api（新版本的设计思路不同，略过）是这样的：</p><p> </p><p>$import(uri:String):packageObject</p><p>$import(packageNamespace:PackageNamespace):packageObject</p><p> </p><p>前者的例子如：</p><p>$import("http://www.example.com/scripts/lib/test/pkg1.js#ClassA,ClassB;ClassC,ClassD");</p><p>后者的例子如：</p><p>$import(pies.test.pkg1);</p><p> </p><p>$import调用会返回容器，比如可以：</p><p>var my = $import(pies.test.pkg1);</p><p>var c = new my.ClassC();</p><p> </p><p>这里源于一个与jsi不同的设计，就是一个package里会定义某些name是直接到global，某些是不会到global（这个设计是按照moz老的JS2草案和参考perl的module的），必须通过pkg = $import()调用来获得pkg对象。<br/><br/>此外，这里没有考虑异步加载的问题。</p><p><br/>然而，在我完成旧pies之后，我逐渐觉得import到全局空间是存在一定问题的。这其实削弱了pies（或jsi或类似方案）的意义，因为全局空间上导入的名字总是越来越多。</p><p> </p><p>理想状况是始终导入到target，强制使用者首先考虑import到一个容器的方式，而不是直接什么都码到全局空间。我考虑了这样一种API：</p><p> </p><p>var my = $import(jsipkg1);</p><p>my.$import(jsipkg2);</p><p>my.$import(jsipkg3);</p><p> </p><p>即在返回的容器上带有$import方法。这样，可以如此：</p><p> </p><p>var my =</p><p>$import(jsipkg1).</p><p>$import(jsipkg2).</p><p>$import(jsipkg3);</p><p> </p><p>当然这样存在一个问题，即无法判断是否导出到global。这也是我的用意，不允许直接导出到global，如果要导出到global，则必须通过某种显式声明。比如</p><p>$import(jsipkg1).</p><p>$import(jsipkg2).</p><p>$import(jsipkg3).</p><p>to(window);</p><p> </p><p> </p><p>后来，我转向了pies新的设计（其实也不新了，但是我设计完毕后一直没有全部实现，惭愧）完全抛弃了这个做法，因为所有的命名空间都是托管的，所以就没有这个问题了。</p><p> </p><p>因为jsi现在也致力于core的部分，我建议jsi也可以考虑一下怎么降低import到全局空间的负面影响。</p><p> </p><p>如果就现有的API来说，lazy参数其实无所谓，我一向认为import的语义最好不要包含异步loading的问题，也就是是否异步不要在import时指定（或许可以在定义module依赖时指定）。</p><p> </p><p>其实可以考虑把target提前，即import path, target 改为 import target, path。此外就算要加上col，也不必一定需要指定target的。</p><p>这样API其实是：</p><p> </p><p>$import (target:Object, path:String)</p><p>$import (path:String)</p><p>$import (path:String, onload:Function)</p><p>$import (path:String, lasy:Boolean)</p><p>$import (target:Object, path:String, onload:Function)</p><p>$import (target:Object, path:String, lazy:Boolean) </p><p> </p><p>这个重载是可以区分的。</p>

11 楼 hax 2008-02-10  

yeaha 写道

我认为jsi的核心价值就是非侵入性的解决了js库的依赖问题，其它的装饰引擎、DOC、IDE这些都或多或少有人在做，而jsi解决的依赖问题貌似很少有人在做（js层面上的，服务器端解决依赖的貌似多一些）

我用google搜索了"javascript dependency"关键字，仅仅发现一个叫JSLoad的有点意思，但是也不如jsi强大，所以在这一块上，最值得期待的就是jsi

如果你是说www.jsloader.com，那个东西不行，我看过了。

10 楼 Army 2008-02-10  

大为我今天思考了个jstg的雏形想法，不知道如何，提提你的意见吧～

http://bbs.ffsky.com/disp.aspx?ID=1655442&bid=17

9 楼 jindw 2008-02-10  

我暂时不会考虑写英文文档的。
外语水平有限，对我来说，写英文文档是很累的差事。
再者，JSI还有很多事情可以做，低调，一定要低调，呵呵。

至于其他框架的支持，我也暂时不会跟进，除非自己用到。

8 楼 Stainlesssteel 2008-02-10  

如果能提供英文文档,注释业附上英文,应该能吸引更多关注

还有就是把主流框架 prototype jquery mootools之类的例子都添加上去

7 楼 yeaha 2008-02-08  

其实我就是想偷懒而已，你把extjs集成好了我来用，哈哈
不过即使你不做，我自己也打算做（打算，打算而已……），毕竟你已经提供了工具

6 楼 jindw 2008-02-08  

以前做过一些其他类库的集成，但最后因为没有机会真正去使用他们，最终也都是不了了之。

而内核，至少工作种还用到了，还可以延续下去。

5 楼 jindw 2008-02-08  

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

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

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

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

4 楼 yeaha 2008-02-08  

我认为jsi的核心价值就是非侵入性的解决了js库的依赖问题，其它的装饰引擎、DOC、IDE这些都或多或少有人在做，而jsi解决的依赖问题貌似很少有人在做（js层面上的，服务器端解决依赖的貌似多一些）

我用google搜索了"javascript dependency"关键字，仅仅发现一个叫JSLoad的有点意思，但是也不如jsi强大，所以在这一块上，最值得期待的就是jsi

目前extjs风头很劲，开发人员逐渐增加，如果jsi能够很好的解决好extjs的问题，也许jsi会成为很多extjs使用者的标配，对jsi的推广很有帮助。extjs当初也是从yui社区获得了大量用户

站着说话不腰疼的就是我，哈哈

JSLoad
http://www.instructables.com/blog/B2OLM73F5LDFN2Z/

3 楼 jindw 2008-02-08  

呵呵，其实我也一直想集成Extjs，可是又不敢搞了。
时刻提醒自己，别冲动，千万别冲动。

现在JSI各方面拉的太开，好像什么都想做，装饰引擎、JSIDoc、IDE。等等等等。
而现在各方面又都没有足够的时间，如JSIDoc已经很久没有更新，已经不能兼容现有JSI版本。。。。

所以，只能收缩战线，先主攻内核优化，IDE支持。其他的慢慢来。或者干脆抛弃。

2 楼 yeaha 2008-02-08  

期望jindw可以用jsi弄一个extjs的样例，extjs如果通过jsi加载就可以解决掉很头疼的文件太大问题了
extjs + jsi，想想都觉得很爽，嘿嘿
谢谢jindw的无私分享

1 楼 jindw 2008-02-07  

<p>刚才和<a href='http://zsp.iteye.com/' target='_blank'>小张</a>讨论了一下，更倾向于仍外一种方式</p><p> </p><pre name='code' class='java'>$import(path,colot,col)</pre> <p><br/><br/>即：</p><pre name='code' class='js'>$import(path,
            callbackOrLazyLoadOrTarget)
$import(path,
            target,
            callbackOrLazyLoad)</pre> <p> </p>