海纳百川 有容乃大――采用JSI封装、集成第三方类库

海纳百川 有容乃大－－封装、集成

Java的成功，离不开它那个庞大的类库，不单是sun的类库，很多细节的实现都取自第三方（如xml解析采用Apache的实现）。

如前言所述，我们暂时不大算编写丰富的公共API，但是我们可以集成其他成熟的类库，同时隔离他们的依赖，隔离各个脚本的执行上下文，消除命名冲突的危险。

这里我们详细介绍一个复杂一点的实例：类似Windows XP文件浏览器左侧的滑动折叠面板(任务菜单)效果。

我们先集成Scriptaculous Effect类库，并且在这个基础上按我个人的习惯对一个面板折叠效果做一个简单的封装，展示框架的类库封装功能。

1．  集成Scriptaculous类库：

这里我们不做过多介绍，详细情况请参考集成实战；我们发布的版本中已经把Scriptaculous放置于us.aculo.script包中，您可以把这些作为系统内置的类库使用。

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

/**  * 滑动面板实现.  * 当指定元素可见时，将其第一个子元素向上滑动至完全被遮掩（折叠）。  * 当指定元素不可见时，将其第一个子元素向下滑动至完全显示（展开）。  */ function slidePanel(panel){   panel = $(panel);   if(panel.style.display=='none'){     //调用Scriptaculous Effect的具体滑动展开实现     new Effect.SlideDown(panel);   }else{     //调用Scriptaculous Effect的具体滑动闭合实现     new Effect.SlideUp(panel);   } }

3．  编写包定义脚本（org/xidea/example/display/__$package.js）：

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

4．  编写我们的 HTML 代码：

< html >
   < head >  
   < title > 重用aculo Effect脚本实例 </ title >
   < link  rel ="stylesheet"  type ="text/css"  href ="/styles/default.css"   />
   < script  src ="/scripts/boot.js" ></ script >
   < script > ...
    $import("org.xidea.display.slidePanel");
   </ script >
   </ head >
   < body >
     < div  class ="menu_header"
        onclick ="slidePanel('menu_block1')" >
        面板 1
     </ div >
     < div  class ="menu_block"  id ="menu_block1" >
       < ul >
         < li > text1 </ li >
         < li > text2 </ li >
         < li > text3 </ li >
       </ ul >
     </ div >
</ body >
</ html >

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

1.1      壁立千仞 无欲则刚――控制依赖

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

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

JSI的出现，可以解决上述问题，我们建议类库的开发者将自己类库的依赖终结在自己手中，避免依赖扩散，以提高类库的易用性。

同样使用上面的例子，假如我们想抛开JSI，实现同样的功能，那我们的页面代码将是（类库代码不用改动）：

< html >
   < head >  
   < title > 重用aculo Effect脚本实例 </ title >
   < link  rel ="stylesheet"  type ="text/css"  href ="/styles/default.css"   />
   <!--
  <script src="/scripts/boot.js"></script>
  <script>
    $import("org.xidea.display.slidePanel");
  </script>
-->
< script  src ="/scripts/net/conio/prototype/v1_5/prototype.js" >
</ script >
< script  src ="/scripts/us/aculo/script/v1_7/effects.js" >
</ script >
< script  src ="/scripts/us/aculo/script/v1_7/builder.js" >
</ script >
< script  src ="/scripts/org/xidea/display/effect.js" >
</ script >
   </ head >
   < body >
     < div  class ="menu_header"
        onclick ="slidePanel('menu_block1')" >
        面板 1
     </ div >
     < div  class ="menu_block"  id ="menu_block1" >
       < ul >
         < li > text1 </ li >
         < li > text2 </ li >
         < li > text3 </ li >
       </ ul >
     </ div >
</ body >
</ html >

这个例子的html代码明显比上面的复杂了，一堆堆的script标签，而且还是有序的；还出现在页面上，重构起来也极其麻烦。

可以看出，JSI的加入可以让类库更加易用，html代码更为简洁，最终用户已经不必关心所用类库的依赖了。

JSI中每一个脚本有一个单独的执行上下文。各个脚本顶部变量你可以随便使用，不必担心不同脚本中的命名冲突，不会污染全局变量空间，这种方式可以用于解决某些类库间变量冲突的问题（如jQuery和Prototype的$函数）。我们甚至可以做到同一个页面上间接加载同一种类库的两个不同版本，不相互影响。

使用JSI后，很多细节我们可以在包中封装掉，不需要告诉类库使用者太多。大大增加类库的易用性。同时，类库封装的支持可以让我们在第三方库的基础上轻松的按自己的喜好编写自己的类库，同时避免依赖扩散造成的复杂度增加。

使用JSIntegration唯一多出的负担就是编写包定义文件，不过想想这种定义文件可是一劳永逸的（以后就不需要每次导入脚本的时候都小心翼翼的判断那个脚本先导入那个后导入，有那些间接使用到的类库需要导入，等等），而且有了包结构后对于代码组织、重用，以及文档的编写阅读，都将非常有利。