论坛首页 → Web前端技术论坛 →

JavaScript Integration 入门教材

浏览 8664 次
锁定老帖子 主题：JavaScript Integration 入门教材
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
  • jindw
  • 等级: 三钻会员
  • 性别:
  • 文章: 731
  • 积分: 1481
  • 来自: 初到北京
   发表时间：2007-04-15  

JSI是一个简单、无侵入（被管理的脚本无需考虑JSI的存在）的脚本管理框架， JSI的出现，可以做到如下几点。

  • 按需装载。
  • 管理依赖，避免依赖的保露、扩散，提高类库的易用性。
  • 执行环境的隔离，避免名称冲突。

类库装载<o:p></o:p>

动态装载类库是按需装载的基础，JSI的装载方式有三种：即时同步装载（可能阻塞）、延迟同步装载（需要编译）、异步装载。这里先演示一下最简单的方式，即时同步导入：

示例：重写一下jQuery的hello world。

xml 代码
 
  1. ….  
  2. <script src="../scripts/boot.js">>  
  3. ….  
  4. <script>  
  5. //导入jQuery的$函数  
  6. $import("org.jquery.$");  
  7. //使用jQuery的$函数  
  8. $(document).ready(function(){  
  9.   alert("Hello World");  
  10.  });  
  11. <script>  
  12. ….  

这是默认的导入方式，当能，如果网络环境不好，这可能产生阻塞问题。所以JSI2开始增加了仍外两种导入模式。延迟同步导入，异步导入。具体用法请查看文章后面的导入函数参考。

<o:p></o:p>

依赖管理<o:p></o:p>

Java可以随意的使用第三方类库，可是JavaScript却没那么幸运，随着类库的丰富，烦杂的依赖关系和可能的命名冲突将使得类库的发展越来越困难。程序的易用性也将大打折扣。<o:p></o:p>

命名冲突的危险无形的增加你大脑的负担；随着使用的类库的增加，暴露的依赖也将随之增加，这是复杂度陡增的极大祸根，将使得系统越来越复杂，越来越难以控制。潜在的问题越来越多，防不胜防。<o:p></o:p>

所以，我们建议类库的开发者将自己类库的依赖终结在自己手中，避免依赖扩散，以提高类库的易用性。

为了演示一下JSI的依赖管理，我们编写一个复杂一点的类库：类似Windows XP文件浏览器左侧的滑动折叠面板(任务菜单)效果。

  编写我们的折叠面板函数（org/xidea/example/display/effect.js）：

js 代码
 
  1. /** 
  2.  * 滑动面板实现. 
  3.  * 当指定元素可见时，将其第一个子元素向上滑动至完全被遮掩（折叠）。 
  4.  * 当指定元素不可见时，将其第一个子元素向下滑动至完全显示（展开）。 
  5.  */  
  6. function slidePanel(panel){  
  7.   panel = $(panel); 
  8.   if(panel.style.display=='none'){ 
  9.     //调用Scriptaculous Effect的具体滑动展开实现 
  10.     new Effect.SlideDown(panel); 
  11.   }else{ 
  12.     //调用Scriptaculous Effect的具体滑动闭合实现 
  13.     new Effect.SlideUp(panel); 
  14.   } 
  15. }  
   

编写包定义脚本，申明其内容及依赖（org/xidea/example/display/__$package.js）：

js 代码
 
  1. //添加slidePanel（滑动面板控制）函数  
  2. this.addScript("effect.js","slidePanel",null);  
  3. //给effect.js脚本添加对us.aculo.script包中effects.js脚本的装载后依赖this.addScriptDependence("effect.js",  
  4. "us/aculo/script/effects.js",false);  
  5. //给effect.js脚本添加对net.conio.prototype包中$函数的装载后依赖this.addScriptObjectDependence("effect.js",  
  6. "net.conio.prototype.$",false)  

 HTML代码：

xml 代码
 
  1. <html>  
  2.   <head>   
  3.   <title>重用aculo Effect脚本实例title>  
  4.   <link rel="stylesheet" type="text/css" href="/styles/default.css" />  
  5.   <script src="/scripts/boot.js"><!---->script>  
  6.   <script>  
  7.     $import("org.xidea.display.slidePanel");  
  8.   <!---->script>  
  9.   <!---->head>  
  10.   <body>  
  11.     <div class="menu_header"  
  12.         onclick="slidePanel('menu_block1')">  
  13.         面板 1  
  14.     <div>  
  15.     <div class="menu_block" id="menu_block1">  
  16.       <ul>  
  17.         <li>text1li>  
  18.         <li>text2li>  
  19.         <li>text3li>  
  20.       <ul>  
  21.     <div>  
  22. <body>  
  23. <html>  


onclick="slidePanel('menu_block1')"这个事件函数将在我们点击面板标题时触发，能后会调用Scriptaculous Effect的具体实现去实现我们需要的滑动折叠功能。

<o:p> </o:p>

这个效果只是八行代码，比较简单，但是它用到了Scriptaculous Effect类库，Scriptaculous Effect又简接用到了Prototype类库，所以，传统方式使用起来还是比较复杂，有一堆脚本需要导入prototype.js，effects.js，builder.js，更加痛苦的是这些脚本的导入还要遵守一定的顺序。

  但是，如果我们使用JSI 明确申明了这些依赖，那么使用起来就简单多了，只一个import就可以完全搞定。<o:p></o:p>

    此外 这里还有一个额外的好处，我们类库中依赖的那些脚本，并不会对外部保露，在页面上是不可见的，也就是说，这些依赖完全终结在刚才编写的类库中，不必担心使用这些类库带来的名称污染问题。<o:p></o:p>

环境隔离<o:p></o:p>

众所周知， Scriptaculous所依赖的Prototype库与jQuery存在冲突。所以同时使用比较困难。

下面的例子，我们将在同一个页面上同时使用Scriptaculous和 jQuery 类库。示范一下JSI隔离冲突功能。

示例页面（hello-jquery-aculo.html）：

xml 代码
 
  1. <html>  
  2. <head>  
  3. <title>Hello jQuery And Scriptaculous<!---->title>  
  4. <!---->  
  5. <script src="../scripts/boot.js"><!---->script>  
  6. <script>  
  7. //导入jQuery  
  8. $import("org.jquery.$");  
  9. //导入Scriptaculous  
  10. $import("us.aculo.script.Effect");  
  11.   
  12. $(document).ready(function(){  
  13.   //使用jQuery添加一段问候语  
  14.   $("<p id='helloBox' style='background:#0F0;text-align:center;font-size:40px;cursor:pointer;'>Hello jQuery And Scriptaculous<!---->p>")  
  15.     .appendTo('body');  
  16.   $('#helloBox').ready(function(){  
  17.     //使用Scriptaculous高亮显示一下刚才添加的内容  
  18.     new Effect.Highlight('helloBox');  
  19.   }).click(function(){  
  20.     //当用户单击该内容后使用jQuery实现渐出  
  21.     $('#helloBox').fadeOut();  
  22.   });  
  23.  });  
  24. <!---->script>  
  25. <!---->head>  
  26. <body>  
  27. <p>文档装载后，jQuery将在后面添加一段问候语；并使用Scriptaculous高亮显示（Highlight）；在鼠标点击后在使用jQuery渐出（fadeOut）。<!---->p>  
  28. <!---->body>  
  29. <!---->html>  

其他话题<o:p></o:p>

JSI组件模型：

页面装饰引擎：用于装饰朴素html元素的框架，实现零脚本代码的web富客户端编程，更多细节请访问jsi官方网站。

<o:p> </o:p>

<o:p> </o:p>

参考：<o:p></o:p>

脚本导入函数<o:p></o:p>

脚本导入函数是JSI唯一的一个在页面上使用的系统函数。

  function $import(path, callbackOrLazyLoad, target )

      path 类库路径

      callbackOrLazyLoad 可选参数,如果其值为函数，表示异步导入模式；如果其值为真，表示延迟同步导入模式，否则为即时同步导入（默认如此）。

      Target 可选参数(默认为全局变量,所以说,这种情况等价于直接声明的全局变量)，指定导入容器。
返回顶楼
         
  • cozone_柯中
  • 等级: 五星会员
  • 性别:
  • 文章: 225
  • 积分: 464
  • 来自: 湖北武汉北京
   发表时间：2007-04-15  
jsi 确实不错,不过觉得这个东西是否能流行, 在于人们打破常规的写js的习惯和思维模式
返回顶楼
          回帖地址
0 请登录后投票
  • jindw
  • 等级: 三钻会员
  • 性别:
  • 文章: 731
  • 积分: 1481
  • 来自: 初到北京
   发表时间：2007-04-15  
cozone_柯中 写道
jsi 确实不错,不过觉得这个东西是否能流行, 在于人们打破常规的写js的习惯和思维模式


不明白，为什么要打破常规？ JSI托管的代码与平常的代码没有什么区别啊。
原来喜欢prototype还用他的prototype，原来jquery的还用他的jquery。
只不过页面上的引入方式变了，原来一坨坨script标记换成$import指令

不过JSI的组件模型倒有点打破常规：
http://jsi.xidea.org/decorator/index.html
可以先预览一下，文档还没写。
返回顶楼
          回帖地址
0 请登录后投票
  • cozone_柯中
  • 等级: 五星会员
  • 性别:
  • 文章: 225
  • 积分: 464
  • 来自: 湖北武汉北京
   发表时间：2007-04-15  
jindw 写道
cozone_柯中 写道
jsi 确实不错,不过觉得这个东西是否能流行, 在于人们打破常规的写js的习惯和思维模式


不明白，为什么要打破常规？ JSI托管的代码与平常的代码没有什么区别啊。
原来喜欢prototype还用他的prototype，原来jquery的还用他的jquery。
只不过页面上的引入方式变了，原来一坨坨script标记换成$import指令

不过JSI的组件模型倒有点打破常规：
http://jsi.xidea.org/decorator/index.html
可以先预览一下，文档还没写。


现在打不开页面,我记得没错的话是装饰框架的页面, 其实我觉得jsi好就好在这个模式,其他模式很容易就可以在现有项目里实现 1. 同步加载 2.延时同步加载. 3.异步延时加载 4.就是装饰模式了
返回顶楼
          回帖地址
0 请登录后投票
  • bellstar
  • 等级: 三星会员
  • 性别:
  • 文章: 56
  • 积分: 330
  • 来自: 上海
   发表时间：2007-05-31  
·避免冲突可以像强类型语言样的用namespace来实现,像prototype这样的为没有像YUI那样的统一前缀,可以自己一次性加啊。
·按需加载的话，我觉得还是如果有IDE工具来实现比较好。
也可自己写一个js代码分析转换程序，如果调用了某个namespace下的东西就分析他在该namespace下的继承性，然后从中抽取出这部分js代码直接存档。当然也可以向服务器请求时动态生成js，但要耗时间，还不如开发时就搞定。
·异步加载js的话我个人认为在某些特殊情况下可行（代码上万行），但如果实现了按需加载的话，我想js代码不会影响多少下载速度，毕竟是文本啊，行数不多的话，检查语法也不会影响多少。
异步加载肯定是有延迟的，而且还要处理异步错误，对服务器的连接次数也多了也是负担。因此，普通情况下就不太适用了。
以上言论,我只是想到了,没有去做。光说不练，嘴皮子厉害。见笑了。zhongxingdou@126.com 俺是吉安的哦。
返回顶楼
          回帖地址
0 请登录后投票
  • jindw
  • 等级: 三钻会员
  • 性别:
  • 文章: 731
  • 积分: 1481
  • 来自: 初到北京
   发表时间：2007-05-31  
bellstar 写道
·避免冲突可以像强类型语言样的用namespace来实现,像prototype这样的为没有像YUI那样的统一前缀,可以自己一次性加啊。
·按需加载的话，我觉得还是如果有IDE工具来实现比较好。
也可自己写一个js代码分析转换程序，如果调用了某个namespace下的东西就分析他在该namespace下的继承性，然后从中抽取出这部分js代码直接存档。当然也可以向服务器请求时动态生成js，但要耗时间，还不如开发时就搞定。
·异步加载js的话我个人认为在某些特殊情况下可行（代码上万行），但如果实现了按需加载的话，我想js代码不会影响多少下载速度，毕竟是文本啊，行数不多的话，检查语法也不会影响多少。
异步加载肯定是有延迟的，而且还要处理异步错误，对服务器的连接次数也多了也是负担。因此，普通情况下就不太适用了。
以上言论,我只是想到了,没有去做。光说不练，嘴皮子厉害。见笑了。zhongxingdou@126.com 俺是吉安的哦。


模拟出 namespace,是可以解决部分命名冲突,但是,还是有些小麻烦.
按需装载对于小脚本来说,确实意义不大.不过IDE实现好像也并非王道.
异步加载肯定不是万能的,但是,在某些情况下,还是非常有优势的.

多次小脚本请求确实比请求大点的文件更是负担.所以JSI提供了一种缓存机制,将多个脚本打包到启动文件中,或者外部文件,可以自行加入.这属于性能优化的话题了,我暂时还没有写这方面的文档.
返回顶楼
          回帖地址
0 请登录后投票
  • sp42
  • 等级: 三钻会员
  • 文章: 726
  • 积分: 1617
  • 来自: Canton
   发表时间：2007-05-31  
jindw 写道
bellstar 写道
·避免冲突可以像强类型语言样的用namespace来实现,像prototype这样的为没有像YUI那样的统一前缀,可以自己一次性加啊。
·按需加载的话，我觉得还是如果有IDE工具来实现比较好。
也可自己写一个js代码分析转换程序，如果调用了某个namespace下的东西就分析他在该namespace下的继承性，然后从中抽取出这部分js代码直接存档。当然也可以向服务器请求时动态生成js，但要耗时间，还不如开发时就搞定。
·异步加载js的话我个人认为在某些特殊情况下可行（代码上万行），但如果实现了按需加载的话，我想js代码不会影响多少下载速度，毕竟是文本啊，行数不多的话，检查语法也不会影响多少。
异步加载肯定是有延迟的，而且还要处理异步错误，对服务器的连接次数也多了也是负担。因此，普通情况下就不太适用了。
以上言论,我只是想到了,没有去做。光说不练，嘴皮子厉害。见笑了。zhongxingdou@126.com 俺是吉安的哦。


模拟出 namespace,是可以解决部分命名冲突,但是,还是有些小麻烦.
按需装载对于小脚本来说,确实意义不大.不过IDE实现好像也并非王道.
异步加载肯定不是万能的,但是,在某些情况下,还是非常有优势的.

多次小脚本请求确实比请求大点的文件更是负担.所以JSI提供了一种缓存机制,将多个脚本打包到启动文件中,或者外部文件,可以自行加入.这属于性能优化的话题了,我暂时还没有写这方面的文档.

类似的问题我们也讨论过 呵呵 见原话：

A:光是一个EXT足够掉头发了，还加入其它库。。真是恶梦啊
其实如果那个库的有做namespace的管理，如yui的，冲突的问题算比较容易解决
B:问题是prototype.js对js各个类型的prototype都做了修改 会有影响别的库使用的可能性
这就是所谓的侵入了 不过如果jsi这类工具能解决这个问题 这方面也是很有用了
A:嗯～JSON官网上的json包也是类似问题。
jack将其加入ext时，也修改了一下，做到不用入侵了Object.prototype
返回顶楼
          回帖地址
0 请登录后投票
  • hax
  • 等级: 四钻会员
  • 性别:
  • 文章: 1543
  • 积分: 1795
  • 来自: 上海
   发表时间：2007-05-31  
jindw 写道
bellstar 写道
·避免冲突可以像强类型语言样的用namespace来实现,像prototype这样的为没有像YUI那样的统一前缀,可以自己一次性加啊。
·按需加载的话，我觉得还是如果有IDE工具来实现比较好。
也可自己写一个js代码分析转换程序，如果调用了某个namespace下的东西就分析他在该namespace下的继承性，然后从中抽取出这部分js代码直接存档。当然也可以向服务器请求时动态生成js，但要耗时间，还不如开发时就搞定。
·异步加载js的话我个人认为在某些特殊情况下可行（代码上万行），但如果实现了按需加载的话，我想js代码不会影响多少下载速度，毕竟是文本啊，行数不多的话，检查语法也不会影响多少。
异步加载肯定是有延迟的，而且还要处理异步错误，对服务器的连接次数也多了也是负担。因此，普通情况下就不太适用了。
以上言论,我只是想到了,没有去做。光说不练，嘴皮子厉害。见笑了。zhongxingdou@126.com 俺是吉安的哦。


模拟出 namespace,是可以解决部分命名冲突,但是,还是有些小麻烦.
按需装载对于小脚本来说,确实意义不大.不过IDE实现好像也并非王道.
异步加载肯定不是万能的,但是,在某些情况下,还是非常有优势的.

多次小脚本请求确实比请求大点的文件更是负担.所以JSI提供了一种缓存机制,将多个脚本打包到启动文件中,或者外部文件,可以自行加入.这属于性能优化的话题了,我暂时还没有写这方面的文档.



以下主要回bellstar，兼和金同志讨论。

自己加前缀并不能解决所有问题。可参考我回dlee的 http://www.iteye.com/topic/78360?page=12，针对本帖重新整理补充如下：

我很能理解jsi的意义，因为我本人也有类似的想法和项目（pies: http://sourceforge.net/pies）。jsi或者我的pies首先考虑的是，解决传统js基础架构的缺失。越是program-in-large，基础架构的作用越是显著。而且jsi和pies对于dlee说的 Unobtrusive、Progressive Enhancement、代码的可测试性、可维护性等问题确实会有帮助。

关于js的侵入性问题，其实非常重要，因为这是做类库的人的痛点！金同志所说的侵入性首先是指你的代码或其他人的第三方代码纳入框架后，是否要对自己作出改动，如果要被迫作出改动，实际上就是被框架侵入了，剩下的只是看侵入的程度如何了。例如jspkg，虽然侵入但是程度很低，只是代码要做一下包装而已。相反dojo以及许多需要显式增加命名空间定义的，恐怕就大很多了。在实际当中，这样很麻烦。例如我用了一个第三方的开源类库，它自己会频繁更新，结果每次更新我都需要重新修改它的源码以适应框架，这是不可忍受的。所以你说给prototype一次性加前缀，就会碰到这个问题，每次prototype升级你都要做一个自己的版本。如果某些第三方类库是以出diff出来的patch来发布小更新，那就要痛苦死了。

而且按需加载并不完全等同于编译语言的类似过程，因为js存在网络loading的问题，一次性打包一个特定版本，虽然也是一种方法，但对于一些对带宽和响应速度要求更高的站点，并不能完全满足。例如，你10个页面的js有稍许不同，打包10个出来显然不是好方法。较好的方式是共同部分打包一个，其他的单独打包或到时按需加载。这需要一个很好的工具，但理论上无论jsi还是pies都可以做到的——通过检查当前所有载入的包，很容易产生。pies的前个版本已经带有这个功能，就是不太自动化。

关于异步加载，我倒是也觉得存在疑问。金同志有更多关于jsi异步加载的细节可以show给我们看看吗？

第二个问题，更加关键，就是引入第三方代码后，是否会造成框架中其他部分甚至框架自身的毁坏？最简单的例子，就是namespace冲突，原先框架自己所需的一个方法被第三方代码冲掉了。这就可以说是框架的抗侵入性。现在许多框架通过一定的手段（如closure），基本能保证自己不被侵入，但是绝大多数框架不能保证两组第三方代码不会互相冲突。例如prototype和jquery乃至许多框架都使用了$这个名字，那能否同时使用两个类库？进一步，有些库基于prototype，有些基于jquery，我能否两者和平共处？

目前就我所知，只有jsi, pies, jspkg（需要对代码进行简单包装）可以做到。

所以也许在只有少数脚本的时候，使用jsi或pies并不能带来很多益处，但是牵涉代码越多，特别是第三方代码很多的时候，jsi和pies这样的框架不仅是提高效率的问题，更重要的是能避免很多潜在的名称冲突造成的问题，而这类问题，不用说，是出了名的难以调试。

另一方面，上述这三个框架都带有类似的log机制可用于debug和简单的unit测试。

最后，我想问一下金同志，$import默认总是导入短名字到global吗？如果在一个被import的脚本内部import第三方库，那第三方库是否不会被导入到global，还是需要通过加最后一个参数来导入到一个对象上去？还有，就是如果import发现已经有这个name了，那是覆盖呢，还是报错啊？
返回顶楼
          回帖地址
0 请登录后投票
  • jindw
  • 等级: 三钻会员
  • 性别:
  • 文章: 731
  • 积分: 1481
  • 来自: 初到北京
   发表时间：2007-05-31  
先谢谢hax的精彩回复,一些概念我自己没有解释清楚过,一看hax的解释,清晰了很多:)

hax 写道
关于异步加载，我倒是也觉得存在疑问。金同志有更多关于jsi异步加载的细节可以show给我们看看吗？

JSI的装饰引擎就是最好的例子.用法在仍外一个帖子里有些http://www.iteye.com/topic/66702,实现原理其实也很简单,构造一个任务队列.
先缓存所需资源,能后用普通方式导入.难点还在于依赖的计算,要一边执行,一边补充结果.

hax 写道
最后，我想问一下金同志，$import默认总是导入短名字到global吗？如果在一个被import的脚本内部import第三方库，那第三方库是否不会被导入到global，还是需要通过加最后一个参数来导入到一个对象上去？还有，就是如果import发现已经有这个name了，那是覆盖呢，还是报错啊？


$import的第三个可选参数可以指定导入目标,默认为global.
仍外,$import函数一般只是页面上使用的,托管脚本内推荐使用申明依赖来代替$import.
这样虽然麻烦些,但是也只有这样才能做到无侵入了,还有,依赖申明代替$import也是实现异步装载的基础.

补充一下:
hax 写道
如果在一个被import的脚本内部import第三方库，那第三方库是否不会被导入到global

对于间接依赖的脚本,会装载,但是不会被导出来.只是被注入到依赖它的装载单元内部.
当能,不是用import,用脚本依赖定义:)
返回顶楼
          回帖地址
0 请登录后投票
  • hax
  • 等级: 四钻会员
  • 性别:
  • 文章: 1543
  • 积分: 1795
  • 来自: 上海
   发表时间：2007-05-31  
jindw 写道

$import的第三个可选参数可以指定导入目标,默认为global.
仍外,$import函数一般只是页面上使用的,托管脚本内推荐使用申明依赖来代替$import.
这样虽然麻烦些,但是也只有这样才能做到无侵入了,还有,依赖申明代替$import也是实现异步装载的基础.

补充一下:
对于间接依赖的脚本,会装载,但是不会被导出来.只是被注入到依赖它的装载单元内部.
当能,不是用import,用脚本依赖定义:)


那就是当前的jsi与pies一样，$import总是导入到global上（不过你还没告诉我冲突的时候是覆盖还是扔异常呢）。pies不使用最后一个参数，但是$import会返回一个对象，如 var myPackage = $import (com.example.test); 然后myPackage.MyClass即可（注：当前pies的import是按照最初moz的es4草案的设计，导入包，而不是导入对象，基本相当于import com.example.test.*）。

但是我正在开发的全新的pies（基本构思在去年11月就完成了，但是一直动作太慢，惭愧），将支持在被导入脚本中的import，并且不会污染global，呵呵。但是如你所说，这种方式是不能异步的，要异步，只有通过外在的依赖声明。另外我的这种内部import需要jscript 5.5开始的以后版本，而且我尚未在safari里和Konqueror里测试过是否可行。我也打算测试rhino和其他非browser的js引擎。
返回顶楼
          回帖地址
0 请登录后投票
论坛首页 → Web前端技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics