BlogJava-jindw的blog-随笔分类-JavaScript

运动曲线研究(缓动效果)

金大为 — Sun, 14 Oct 2007 13:14:00 GMT

摘要: 刚刚学习了一下网页动画中上的缓动效果，分享一下学习心得。缓动曲线的概念：缓动曲线是一个0为起点的连续函数曲线，x轴表示时间变化，y轴表示位移变化。曲线的斜率反映出运动的数度。缓动效果在Flash动画中比较常见，用于模拟一些现实中常见的运动轨迹，或者制造一些超绚的效果。而且新版本的Flash中，内置了一些常用的缓动曲线函数。可惜,Flash的这些曲线函数不是开源的... 阅读全文

金大为 2007-10-14 21:14 发表评论

JSA在线压缩程序发布

金大为 — Wed, 22 Aug 2007 08:28:00 GMT

JSA这个压缩工具，是java编写的，需要安装java运行环境。
这多少给一些非jav程序员带来点不便。

现在我们发布servlet在线压缩版本。无需安装，在线压缩，给非Java用户一个更加便捷的使用方式。

项目主页：http://www.xidea.org/project/jsa/
现在的在线压缩服务器由Seaprince提供。
欢迎更多有空闲服务器资源的朋友安装JSA在线服务，我将在jsa项目主页提供链接，方便大家使用。

仍外，为了避免服务器资源被恶意滥用，我们默认启用了图片验证，服务频率限制等保护设置。
给用户带来些不便，敬请谅解。

金大为 2007-08-22 16:28 发表评论

脚本装载时一个似乎应该有所重视的问题。

金大为 — Sun, 12 Aug 2007 14:22:00 GMT

今天无意间打开了一个CSDN上的个人blog，发现窗口无法拖动，Firefox的标签页也无法切换。

查看代码：

看到Include函数，马上可以想到，它很可能使用了动态包含脚本的设计。

//http://blog.csdn.net/scripts/jsframework.js
window.Include=function(namespace, path)
{
   ..
};
S.load=function(namespace, path)
{

}

仔细阅读这两个函数代码，发现它是通过XMLHttpRequest对象同步装载脚本资源的（对IE，它采用userdata缓存优化）。而这必将导致一种完全阻塞问题（这种问题我在仍外一篇blog上描述过：http://jindw.javaeye.com/blog/66702）。

说到阻塞问题，我想大家可能会以为只是一种下载延迟，其实不然。
下载延迟不是完全阻塞，浏览器依然可以响应用户事件。而同步XHR请求阻塞是一种完全的阻塞。
浏览器在脚本运行与事件响应共用同一个线程（我的猜测）。任何脚本尚在运行时（包括被同步XHR请求阻塞的时间），浏览器将无法响应任何用户事件（无法拖放窗口、切换标签、重画页面等等，就像程序死了一样）。与普通的下载延迟造成的阻塞，感觉明显不同。

我对这个问题可以说深有体会，起初，在构建JSI1的项目站点时。因为网站放在sourceforge上，访问数度不是一般的慢，几个简单的例子，浏览器就要完全阻塞好几妙钟。正是厌恶这种完全阻塞的现象，我才开发了JSI2。

事实上，现在的一堆堆js框架中，采用XHR同步装载资源的有不少，JSVM、dojo、a9engine、hax的pies；其中JSVM， dojo都提供打包工具，将可能装载的脚本打包到启动文件中，所以也可以避免XHR同步请求。不过这样也就失去了部分动态装载的意义了。

总之，我非常讨厌这种完全阻塞现象，认为这个严重影响用户体验。
可能也有些主观因素把，希望听听大家的看法。

金大为 2007-08-12 22:22 发表评论

JS几处怪癖的语义

金大为 — Sat, 30 Jun 2007 08:47:00 GMT

带ID的函数表达式：

var fn = function fnid(){};

按照ECMA262定义,上面这段脚本等价于：

with({fnid:null}){
  var fn = fnid = function(){};
}

注意：fnid在with外是不可见的，但是IE没有严格遵守ECMA规范(同样的情况发生在catch语法上)。在IE上相当于：

var fnid = function(){};
var fn = fnid;

在刚刚发布的JSA1beta上，还不能处理这个问题（新版本将这周内发布）。同时，鉴于这种语法在不同浏览器上表现不同，还是建议尽量避免使用（这点上，我个人还是更喜欢ie的方式）。

var语句：
太常用了，但是，没有注意还是很容易出问题。
var 用来声明全局或函数变量，但是，只是申明，重复申明也不能置空，范围是函数或者全局空间，位置在函数或脚本顶端，与块无关，这些与常用高级语言区别很大。

怪癖的代码

var vaiable =0;
function test(){
   variable =1;//别担心，不会改动全局变量vaiable
   //do ..
   var vaiable;//变量申明无顺序（一律置顶），只是赋值有顺序。
}

常见错误有：

var flag;//这里可能有人（包括我自己）喜欢自做聪明的利用一下变量的初始值undefined
while(!flag){//没准那个角落里面已经给当前函数内同名变量给赋值了就惨了
  //..
}

金大为 2007-06-30 16:47 发表评论

[导入]云想衣裳花想容－－JSI组件模型介绍（二）

金大为 — Wed, 27 Jun 2007 02:35:00 GMT

装饰引擎简介：

系统默认的装饰引擎为：org.xidea.decorator.DecoratorEngine。
JSI装载后，将做如下操作：

判断有无装饰器命名空间声明（xmlns:d= "http://www.xidea.org/taglib/decorator"）
若有，将在文档装载结束后，启动装饰引擎，初始化当前可用的装饰提供者表。（装饰提供者是一个JavaScript包，在注册这种装饰包时可同时指定他的别名，别名*表示默认包）
遍历当前文档，凡是该命名空间的节点，都被看作需要装饰的元素。若当前文档存在装饰元素，启用遮罩（关机效果），页面将不可操作（仍可查阅）。
查找装饰元素对应的装饰类（通过tagName判断类名），采用异步方式动态装载这些装饰器类（不会装载到全局空间），并更新当前进度信息，同时设置装饰器之间的关系（parent,children）。
以深度遍历的方式遍历这些节点，注册组件（以后可以通过$JSI.getComponent函数获取装饰器对象），依次执行他们的before操作，和decorate操作。
完成装饰，取消遮罩，页面进入可用状态。

装饰器规范简介：

装饰器指的是所有拥有decorate成员方法的类。一般来说，可将一组装饰器归为同一个包中（太复杂的装饰器，可将具体逻辑放置在其他包中），能后在配置文件中定义装饰包。
scripts/config.js $JSI.addDecoratorProvider("org.xidea.decorator","xidea","*");

装饰器类包含两个方法before、docorate分别在遍历前（子节点未装饰）和遍历后（子节点装饰完成）调用。

同时，装饰引擎遍历时还将注入如下三个属性：

parent：父装饰器
children：子装饰器集合
attributes：装饰器属性集对象（只有一个成员函数：get(attrName) ）

JSI现有装饰器集合简介

目前JSI2最高版本2.0预览版 (2007-04-16)包含如下装饰器：

DatePicker
日期选择控件，参照xul datepicker标签，支持弹出方式(默认值 type='pop')，和内嵌式(type='grid')
Editor
编辑器控件，参照xul editor标签
Spinner
Spinner控件（window时间日期管理中，年份调节的控件），参照backbase 的 Spinner标签
TabBox、Tabs、Tab、TabPanels、TabPanel
TabBox(标签页)控件，参照xul tabbox标签
Code
代码语法高亮显示控件，参照SyntaxHighlighter的显示风格
Include
片断包含标签，支持xpath选取文档片断，支持xslt转换

这些装饰器的演示见：
http://www.xidea.org/project/jsi/decorator/index.html

目前JSI自带的装饰器不够丰富，而且都还是初级阶段，不够完善。现在发布的这些装饰器，主要是为了演示JSI的工作方式，编码风格，希望能吸引第三方团队、公司在这个基础上开发出自己的更加实用的装饰器集合。

JSI及其装饰引擎采用LGPL协议。可以商业应用，当能，更希望能开源。

目前就我一人之力，开发一套完整的装饰器，尚需时日，这次将这个半成品拿出来演示，主要是为了展示一下jsd的风格，希望能吸引其他开发者，共同参与这个工程，有兴趣丰富JS自带I装饰器集合的网友，请msn与我联系：jindw◎xidea。org

金大为 2007-06-27 10:35 发表评论

[导入]云想衣裳花想容－－JSI组件模型介绍（一）

金大为 — Wed, 27 Jun 2007 02:24:00 GMT

JSI组件模型是一种用来装饰简单html元素的框架，使用简单的xml标记，标识其装饰行为，比如将一个普通的input装饰成一个日期输入控件，将一个html ul标记装饰成菜单或树，将一个textarea装饰成一个代码语法高亮显示区域，或一个wysiwyg html编辑器。
JSI启动后将自动检查decorator标记，构建层次结构，自动做相关类的寻找、导入和装饰操作；实现零脚本代码的web富客户端编程。

代码示例：

日期选择器 (DatePicker):

<d:datepicker>
  <input type="text" name="test2" />
d:datepicker>
编辑器示例 (Editor):

<d:editor>
  <textarea name='editorText'>This is some <strong>sample textstrong>. You are using <a
    href="http://www.fckeditor.net/">FCKeditora>.textarea>
d:editor>
Spinner控件（Spinner 类似window时间日期管理中，年份调节的控件）:

<d:spinner start='0' end='8' step='2'>
  <input type="text" name="test2" value='0' />
d:spinner>
客户端包含(Include):

<d:include url='menu.xml' xslt="menu.xsl">d:include>
代码语法高亮显示控件(Code):

<d:code language="js">
<textarea>alert(‘Hello World’)textarea>
d:code>
标签页控件(TabBox参照xul tabbox标签):

<d:tabbox>
  <d:tabs>
    <d:tab>tab1d:tab>
    <d:tab>tab2d:tab>
    <d:tab>tab3d:tab>
  d:tabs>
  <d:tabpanels>
    <d:tabpanel>content1d:tabpanel>
    <d:tabpanel>content2d:tabpanel>
    <d:tabpanel>content3d:tabpanel>
  d:tabpanels>
d:tabbox>
综合示例:

来一个复杂一点的完整的例子,以日期选择控件的演示页面为例
页面上有: 标签页装饰器（TabBox….）、源代码高亮显示装饰器（Code）、日期选择装饰器（DatePicker）、包含装饰器（Include）

xml version="1.0" encoding="utf-8"?>
DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
  xmlns:d="http://www.xidea.org/taglib/decorator" xml:lang="zh_CN"
  lang="zh_CN">
<head>
<script src="../scripts/boot.js">script>
<title>DatePicker 示例title>
head>
<body>
<h2>DatePicker 示例h2>

<d:tabbox>
  <d:tabs>
    <d:tab>效果d:tab>
    <d:tab>代码d:tab>
  d:tabs>
  <d:tabpanels>
    <d:tabpanel>

      <d:datepicker type='grid'>
        <input type="text" name="test1" />
      d:datepicker>

      <d:datepicker>
        <input type="text" name="test2" />
      d:datepicker>
    d:tabpanel>
    <d:tabpanel>

      <d:code language="xml">
        <textarea>
      
      <d:datepicker type='grid'>
        <input type="text" name="test1" />
      </d:datepicker>
      
      <d:datepicker>
        <input type="text" name="test2" />
      </d:datepicker>textarea>
      d:code>
    d:tabpanel>
  d:tabpanels>
d:tabbox>
<select style="margin-left:120px"><option>弹出的datepicker 可覆盖IE selectoption>select>
<hr />

<d:include url='menu.xml' xslt="menu.xsl">d:include>
body>
html>

装饰结果：

云想衣裳花想容－－JSI组件模型介绍（二）已经发布，那里有装饰过程及其原理的介绍：
http://www.javaeye.com/topic/71425

金大为 2007-06-27 10:24 发表评论

[导入] 百花齐放日月同辉――采用JSI解决不同类库间的冲突

金大为 — Mon, 25 Jun 2007 23:46:00 GMT

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

JSI针对每一个装载的脚本都有完全独立的执行上下文。所以这个问题能在JSI上彻底解决。

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

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

<html>
<head>
<title>Hello jQuery And Scriptaculoustitle>

<script src="../scripts/boot.js">script>
<script>
//导入jQuery
$import("org.jquery.$");
//导入Scriptaculous
$import("us.aculo.script.Effect");


$(document).ready(function(){
  //使用jQuery添加一段问候语
  $("

Hello jQuery And Scriptaculous

")      .appendTo('body');
$('#helloBox').ready(function(){
    //使用Scriptaculous高亮显示一下刚才添加的内容
    new Effect.Highlight('helloBox');
}).click(function(){
    //当用户单击该内容后使用jQuery实现渐出
    $('#helloBox').fadeOut();
});
});
script>
head>
<body>
<p>文档装载后，jQuery将在后面添加一段问候语；并使用Scriptaculous高亮显示（Highlight）；在鼠标点击后在使用jQuery渐出（fadeOut）。p>
body>
html>

金大为 2007-06-26 07:46 发表评论

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

金大为 — Mon, 25 Jun 2007 02:14:00 GMT

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

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

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

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

1。集成Scriptaculous类库：

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

2。编写我们的折叠面板函数（example/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。编写包定义脚本（example/__$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);

4。在网页上运用上面的类库：

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

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

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

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

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

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

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

<html>
  <head>
  <title>重用aculo Effect脚本实例title>
  <link rel="stylesheet" type="text/css" href="/styles/default.css" />

<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/example/effect.js">
script>
  head>
  <body>
    <div class="menu_header"
        onclick="slidePanel('menu_block1')">
        面板 1
    div>
    <div class="menu_block" id="menu_block1">
      <ul>
        <li>text1li>
        <li>text2li>
        <li>text3li>
      ul>
    div>
body>
html>

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

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

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

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

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

金大为 2007-06-25 10:14 发表评论

[导入]脚本安需导入的三种模式的对比

金大为 — Mon, 25 Jun 2007 01:24:00 GMT

何谓安需装载？

脚本程序一般都是下载后执行，当脚本库非常庞大时，一次性下载起来非常费时，传统的解决方式是，按功能模块把脚本写在不同的文件中，页面上手动加入script标签装载指定内容，但是这有一些缺点，类库的使用者需要知道没个脚本之间的关系，顺序要求等等，而不可能要求每个类库使用者都对其非常熟悉，出错的可能性很大。于是很多框架开始支持导入指令，想使用什么一个导入函数就完了，不必一堆堆的script文件，不用小心翼翼的关注着他们的依赖关系。

安需装载可分如下三种模式：

即时同步按需装载（阻塞，JSI、JSVM、dojo）。
最简单的按需装载实现，通过XMLHttpRequest同步装载脚本文件实现。问题是，浏览器使用这种方式同步获取资源时将导致浏览器阻塞：停止响应用户事件、停止页面重画操作。所以，虽然编程最为简单，但是用户体验最差。
异步按需装载（无阻塞，JSI2.0+）。
异步导入，不必多做解释，用户体验好，但是因为其异步特征，处理起来比较麻烦。
延迟同步按需装载（无阻塞，JSI2.0+）。
JSI通过动态预装载功能实现的一种同步获取资源的方法，虽然也是同步，但没有阻塞，可以算时兼顾易用性和用户体验的机决方按。缺点时有一定延迟，当前脚本标签中不可用。

使用方法（JSI示例）

以一个代码语法着色程序为例：
类库位置：example/codedecorator/code.js
页面位置：example/xxx.html

即时同步按需装载

$import("example.codedecorator.Code");

var code1 = new Code();
code1.id = "libCode";
code1.decorate();

异步按需装载

$import("example.codedecorator.Code",function(Code){
var code1 = new Code();
code1.id = "libCode";
code1.decorate();
})

延迟同步按需装载（无阻塞，JSI2.0+）。

<script>"../scripts/boot.js">script>
<script>
$import("example.codedecorator.Code",true);
script>

<script>
var code1 = new Code();
code1.id = "libCode";
code1.decorate();
script>

示例说明：

在线测试

http://jsintegration.sourceforge.net/example/code.html

http://www.xidea.org/project/jsi/example/code.html

参考：

JSI 导入函数： function $import(path, callbackOrLazyLoad, target )

金大为 2007-06-25 09:24 发表评论

[导入]再谈一下DOMContentLoad事件

金大为 — Mon, 25 Jun 2007 01:13:00 GMT

这个问题算是个老问题了。
所以，标题加上一个再字。

我主要说一下模拟这个事件时候容易出现的问题。

对于FF，Opera9，原生DOMContentLoad支持，就不说了，最头疼的是IE。
我最初考虑这个问题的时候，想到的是document的readyState属性。
偷窥一下Dojo的源码，发现它也是基于这个属性去做的，那时，我基本就认准了这个方法。
于是再后来JSI1和JSI2早期的预览版本中，都是基于这个属性做的，后来，有个朋友向我反应，说JSI的装饰引擎在IE上启动比FF慢很多，我当时就猜测，是否是这个DOMContentLoad的问题。

经过测试，发现，确实，readyState必须等待图片装载完成之后才能置为complete。
于是到网上搜索一下其他办法，最终 Dean Edwards的blog上描述的一个基于script defer属性的解决办法胜出：http://dean.edwards.name/weblog/category/dom/onload/
不过，使用document.write打印一段脚本，我真的不喜欢：（

在评论里面我们可以看到一些其他的建议，有人认为 readyState == 'complete' 加 readyState==‘interactive’这个状态可以准确模拟DOMContentLoad。我开始简单测试一下，貌似可行，但是后来发现 readyState==‘interactive’可能受alert等函数影响，就是说，一般情况下，readyState== ‘interactive’时，dom是装载完了的，但是，当你文档装载过程中，调用了alert函数，那么，readyState将提前置为 ‘interactive’。

总之，目前来说，我知道的，只有两个办法可以真正实现IE上模拟DOMContentLoad

最常见的一个错误：

再说一下JSI的DOMContentLoad实现的使用接口。

js.html.EventUtil.addDOMReadyListener(listener ,runAnyCase )

第二个参数用于确保listener 在任何时候都会被调用（FF DOMContentLoad事件如果在事件发生之后设置listener是无效的）

金大为 2007-06-25 09:13 发表评论

JSI2性能测试报告

金大为 — Fri, 22 Jun 2007 07:01:00 GMT

装载效率测试
测试页面见：test/load-eff-test.html

为了测试结果更显客观，我选择了第三方类库的装载测试：
'com.yahoo.yui.*',
'net.conio.prototype.*',
'net.fckeditor.*',
'org.jquery.*',
'us.aculo.script.*'
共22个脚本文件（对于JSI来说还有诺干包定义文件）。

FF2:
标记导入时间（原始方式）:469,469,1047,484,484,437,469,484
同步导入时间:469,453,484,437,469,453
延迟导入时间:921,765,891,906,953,906,922
异步导入时间:859,1093,1141,1031,1641,1125,1078,1093,1157,1141

IE7:
标记导入时间:343,297,297,344,328,328
同步导入时间:281,250,235,235,234,234,250,265
延迟导入时间:922,422,406,391,391,391,407,391
异步导入时间:625,672,672,703,703,672,703,704,688

运行时间测试
测试脚本管理后对新能的影响,影响因素有：全局变量和局部变量的查找时间差异，eval的脚本和script标记直接插入的脚本的可能差异。（这个测试不具有普遍性，这里我主要是测试了一下浏览器对局部变量的访问速度【JSI里面访问变量都是装载单元内的局部变量】，所以故意测试了大量局部变量访问的操作）
测试页面见：test/runtime-eff-test.html

FF2：
jsiTime:        845,    927,    598,    687,    764,
scriptTime:     1432,   950,    1305,   1278,   1219,
evalTime:       1644,   1373,   1322,   1186,   1360,
execTime:       0
dscriptTime:    1432,   950,    1305,   1278,   1219,

IE7:
jsiTime:    295,    205,    157,    315,    156,    142,    375,    328,    172,    172,
scriptTime: 172,    172,    189,    140,    251,    187,    217,    203,    172,    234,
evalTime:   236,    249,    139,    172,    281,    171,    172,    108,    436,    359,
execTime:   219,    234,    314,    157,    220,    266,    204,    234,    187,    95,
dscriptTime:    187,    265,    294,    326,    187,    328,     141,   221,    127,    249,

上面的基数太小，随机误差太大，调整原始数据从新测试一遍jsiTime和scriptTime

jsiTime: 576, 658, 688, 703, 611, 608,
scriptTime: 706, 608, 562, 547, 655, 657,

总结：
JSI的装载性能表现不错，完全不必计较。
托管代码的运行性能也没有太大区别，不过，因为。JSI托管脚本使用的变量基本都是装载单元内的局部变量（本地声明变量，或者外部依赖的引用或值拷贝），所以，对于FF这类局部变量比全局变量访问速度快不少的解释引擎，JSI托管脚本可以达到更好的运行效率。

有个奇怪的问题，JSI在装载类库时，与传统模式相比，肯定增加了些额外的运算，但是，貌似JSI的同步装载模式下，装载脚本的耗时比传统模式还少（IE 表现明显）？为何？
欢迎大家对这奇怪的现象提出自己的猜想，我稍后贴出我对此问题的看法^_^

金大为 2007-06-22 15:01 发表评论

JSI2Alpha及JSA1beta 发布：

金大为 — Fri, 22 Jun 2007 06:36:00 GMT

JSI简介：

JSI 是一个开放的、无侵入的脚本库管理框架，内核不提供任何具体功能，有一些功能子项目，如网页装饰引擎。

更多信息请查看：http://www.xidea.org/project/jsi/

JSA简介：
JSA最初是做JSI编译处理的一个小工具，现在也可以用来混淆、压缩脚本。支持swing和ant task两种工作方式。
可以通过webstart启动：启动JSA（允许访问文件系统），沙箱内运行（功能受限）

这次发布的JSI2Alpha相对于以前的预览版本，做了一次全面的重构；同时对API做了些简化。

目前JSI2的公开API有：

/* 导入函数 */
$import(<string>path,<boolean|Function>callbackOrLazyLoad[可选参数],<Object>target[可选参数])

/* 日志设置相关 */
$JSI.setDefaultLogLevel(level)
$JSI.setLogLevel(pathPattern,level)

/* 装饰引擎相关函数 */
$JSI.addDecoratorProvider(pkg,alias…) //添加装饰包.
$JSI.decorate ( ) //准备执行装饰器任务,一般在配置文件（config.js）中调用.

/* 用于包定义的Package成员函数，在__package__.js中调用（this指向当前package对象） */
this.addScript(scriptPath,objectNames)//添加脚本及其声明的对象（函数、方法名）.
this.add*Dependence(thisPath,targetPath,beforeLoad)//添加脚本依赖.
this.setImplementation(realPackage)//设置具体实现包(当前包只是其别名，并无任何内容)。

我们会尽量将JSI做成与具体功能无关（专著于脚本管理）。

对于js.*.*这个类库，做了些精简。
只保留下列元素

#js.html //保留这个包，因为这些实在太常用了。
   * BrowserInfo
   * EventUtil
   * StyleUtil

#js.util//保留这个包主要因为异步装载用到这些类库
   * LoadTask
   * Request
   * ScriptLoadTask
   * TaskQueue

发布文件说明：
自该版本启，source目录将不再打包。
但是在scripts目录下新增boot-with-source.js文件，该文件中包含全部源代码的数据。
里面编码的源代码可以通过我们的文档工具查看。让大家习惯一下这个工具的使用：）

JSA1beta：增加了对JSI2的编译支持，同时对于普通脚本的压缩，也增加了一些功能：
1. ant task 增加多文件分组合并。
2. swing ui 修正文件编码的bug。

下载：
javaeye group: http://jsi.group.javaeye.com/shares
sourceforge: <系统最近好像有问题，我的文件一直没能上传成功,要过一段时间再说> 。。。。。

金大为 2007-06-22 14:36 发表评论

貌似Opera的一个bug

金大为 — Wed, 20 Jun 2007 13:42:00 GMT

今天抽空测试了一下JSI当前状态的浏览器兼容性，一个头疼的问题困扰了很久。
找出问题出自，怀疑是一个opera的bug。

function test(x){
  try{
    if(x){
      return 1;
    }else{
      return 2;
    }
  }catch(e){
    x=1;
  }finally{
    x=2;
  }
}

语法检查就通不过，报告错误：
le://localhost/D:/eclipse/workspace/JSI/web/scripts/core.js
Event thread: BeforeExternalScript

opera8报错，opera9好像就没有这个问题。
贴出来，让有类似问题的人省点心。

金大为 2007-06-20 21:42 发表评论

JavaScript模板引擎测试，让我空欢喜一场：（

金大为 — Fri, 08 Jun 2007 08:15:00 GMT

测试了一下trimpath模板引擎和一个我以前编写xml模板引擎，显示测试结果，828/16。

太让我振奋了。原想，如果效率太低我就放弃这个项目，貌似结果：这个流行的js模板引擎，和我没做优化的xml模板引擎还有这么大的差距？？？

仔细检查一下，晕倒，测试模板数据搞错了：（

纠正过来，测试数据显示，trimpath比xml模板引擎要快好几倍：（

而且，如果模板内使用的循环次数越多，差距越大：（

比较扫兴的结果。
决定吧这个东西从jsi系统api中删除。

不过，感觉，虽然有这点差距，xml模板引擎还是可以作为一个备用选择。
基于js标记库，类el表达式，对于熟悉jsp2.0，jstl的程序员来说，还是比较易懂，扩展也相对简单（trimpath没怎么研究，或许是错的）。

下载测试：
（XML Template是从jsi中拉出来的，部分测试中没有用到的依赖没有包括进去）

金大为 2007-06-08 16:15 发表评论

用正则在Eclipse上对javascript批量缩进。

金大为 — Fri, 08 Jun 2007 03:33:00 GMT

一直没有找到好用的 javascript格式化工具，不过UE有个非常漂亮的功能，多行编辑，可以轻松的批量缩进。
但是eclipse呢？很遗憾，没有，不过用正则表达式可以轻松完成这个功能，匹配整行，替换时在行前加上缩进空格。

find：^.*
replace With： $0

说到这个正则，鄙视一下js的正则语法，居然匹配组是 $1 $2 $3 ....索引从1开始，但是匹配全部为什么要来个$&? 多么难记？？还是eclipse的$0方便
而且js的match函数返回的数组还是 [全匹配,组1，组2....]，全匹配索引就是0嘛！居然要来个$&??
扼杀我们的联想天性。

金大为 2007-06-08 11:33 发表评论

正则表达式实现JavaScript日期格式化的想法。

金大为 — Thu, 07 Jun 2007 08:27:00 GMT

今天和网友聊起在javascript里面实现DateFormat 的话题。

把想法发布一下，当是笔记。

格式化：
1、先用正则把日期表达式分段：
var tokens = "yyyy-MM-dd(没有时间)".match(/y+|M+|d+|m+|[^yMdm]+/g)
//结果数组为：yyyy,-,MM,-,dd,(没有时间)
2、将其中的yyyy MM dd 替换成相映的处理对象

3、格式化时，先复制数组，依次遍历，如果元素是处理对象，那么元素值替换成处理结果。

4、将新数组join。即为需要结果。

5、parse时。先复制数组，若元素为字符串，精确匹配。若未处理对象，读取需要的值，匹配失败，则终止操作，返回结果。

想法而已，实际实现时可能还有很多现在无法意料的事情：）

金大为 2007-06-07 16:27 发表评论

JSI API之BrowserInfo、EventUtil讨论

金大为 — Wed, 06 Jun 2007 04:17:00 GMT

JSI 自身提供一些常用API，数量极少，尽量以一种正式的风格提供，尽量回避争议。
有些是启动文件用到的，如任务队列支持，还有如装饰引擎直接用到的，如BrowserInfo、EventUtil、StyleUtil等。
对于启动文件中未直接用到的，如果风格的争议太大，都将剔除出去。

BrowserInfo对象：

/**
* BrowserInfo 对象，用于判断浏览器的相关信息，如浏览器类型、quirks模式、客户端语言（简体中文？英语..未实现）、操作系统（未实现）等等。
* @public
*/
var BrowserInfo = {
  isIE : falseChecker,
  isOpera : falseChecker,
  isGecko : falseChecker,
  isNetscape : falseChecker,
  isMozilla : falseChecker,
  isFirefox : falseChecker,
  isKhtml : falseChecker,
  isSafari : falseChecker,
  isKonqueror : falseChecker,
  isQuirks : function(){…}
};

其中最常用的要数 is<浏览器类别>（最小版本号码,最大版本号）。
此外，我还将BrowserInfo的函数拷贝到navigator对象上，这个有无必要呢？

//@Deprecated ???
for(var n in BrowserInfo){
window.navigator[n] = BrowserInfo[n];
}

不同之处：

现在在浏览器判断上面，一般是用常量表示，比如isIE之类的，JSI的BrowserInfo使用函数，以便提供更强大更灵活的功能。

EventUtil
EventType 对象的成员函数有：

addListener(el, type, fn, cap)
removeListener(el, type, fn, cap)

addListener(element, listener, captrue)
如addLoadListener，addMousedownListener，addMouseoutListener
removeListener(element, listener, captrue)
createEvent(type, canBubble, cancelable)
dispatchEvent(el, even)

其中: 代表一种事件类型。
W3C事件类型有：

var events = ['click','mousedown','mouseup','mouseover','mousemove','mouseout','load','unload','abort','error','select','change','submit','reset','focus','blur','resize','scroll'].
concat(['DOMFocusIn','DOMFocusOut','DOMActivate']);

此外，还添加了一种事件类型：DOMLoad。就是mozilla的DOMContentLoaded事件，在Dom树构造完成但图片资源等可能未完成时触发。
对于这种事件类型， element, captrue参数都将忽略。暂时只有添加函数，没有删除函数（有删除的必要吗？）。

不同之处：

这个事件处理函数集与其他常见方式的却别有：

this支持。IE的attach方法添加的函数，运行时this指向window对象，JSI吧这点给纠正过来，与w3c的addEventListener行为一致。
事件类型直接体现在函数名中，这样有利于书写上的错误及早发现。
事件格式化，将事件的访问方式格式化为W3C的方式。
自动清理，这也不算不同吧，现在大多数JS库都提供这个功能，就是在离开页面时清理全部注册事件。但是这对一些单页程序是无效的（OPOA，本人也比较讨厌这种模式，呵呵），以后是否可以提供一个purgeElement函数，用于清理指定元素及其子元素的事件呢？

非常希望大家积极发表自己的看法，该修改就修改，如果争议太大，那么我将吧这些从系统API中移除。

程序下载

这个API也可以脱离JSI使用，只是，在编写的时候，因为有了JSI的保护，我使用了不少内部变量，为避免可能的冲突，做了如下处理。

var BrowserInfo = function(){
  //#include(browser-info.js).
  return BrowserInfo;
}

var EventUtil = function(){
  //#include(event-util.js).
  return EventUtil;
}

下载地址

金大为 2007-06-06 12:17 发表评论

javascript 性能测试系列：循环反转的效果

金大为 — Thu, 31 May 2007 04:30:00 GMT

循环反转示例:

  for(var i = 0;i<data.length;i++){
    //.
  }
  //反转后代码
for(var i = data.length-1;i>=0;i--){
    //.
  }

这类优化的作用是明显的,但是具体有多大作用呢?

用一个长度为100 000 的数组测试一下:
515/313
500/313
516/312
516/328
516/328

可见,循环反转后,只需要原来3/5的时间.
但是,这种东西到底有多大价值?FF上200次循环仅需要1毫秒的时间.所以,个人认为,只要循环的内容不是太长,使用不算非常频繁,那么没有太大必要.
加入循环的长度需要通过函数取得,且不变,那么,反转的效率还是可观的,在IE上,函数调用消耗是普通操作的十多倍.

测试代码:

金大为 2007-05-31 12:30 发表评论

javascript 性能测试系列：正则表达式

金大为 — Wed, 30 May 2007 05:22:00 GMT

在JSI的实现中,有这样一种需求,将有自带命名空间的脚本元素名数组转换成没有命名空间的变量名数组.
比如 :
['YAHOO.util.XXXX,YAHOO.util.YYYY,YAHOO.event.XX'] ->['YAHOO']

以前一直是较长的一段处理代码,今天突发奇想,这个用正则表达式处理效果如何?

于是,就这种处理,分别测试了正则表达式和javascript代码的效率.

测试数据如下(regTime /codeTime):
620/4536
729/4068
719/4250
645/4152
655/4642

FF和IE结果差不多,上面是FF2的数据

总结:
经常看见很多地方对正则表达式的效率的怀疑,但是这个问题放在javascript里面,好像情况又不同了. 适当使用正则式,反而可以大大提高效率.
在javascript这类\较慢的解释型语言里面,少即快,能用原生代码就不要自己写.

测试代码:

var data = [];
for(var i = 0;i<20;i++){
  data[i] = "NS"+i/10+'.'+i
}
document.write(
  //(data == data.sort()) +"/"+
  data +"

")
var i = 0;
var regTime = 0;
var codeTime = 0;
var inc = 0;
var reg = /(\b[\$\w]+)[\$\w\.]*(,\1\b[\$\w\.]*)*/g;

var regResult,codeResult;
while(inc++<100){
  var i=0;
  var t1 = new Date();
  while(i++<100){
    regResult = data.join(',').replace(reg,'$1').split(',');
  }

  var t2 = new Date();
  while(i++<200){
    codeResult = [];
    var flagMap = {};
    for(var j=data.length-1;j>=0;j--){
      key = data[j];
      key = key.substr(0,key.indexOf('.'));
      if(!flagMap[key]){
        codeResult[codeResult.length] = (key);
        //codeResult.push(key);
        flagMap[key] = true;
      }
    }
  }
  var t3 = new Date();
  regTime +=(t2-t1);
  codeTime+=(t3-t2);
}
document.write(
  "regResult:"+
  regResult)
document.write(
  "

codeResult:"+
codeResult)
prompt("regTime /codeTime",regTime +'/'+codeTime)

金大为 2007-05-30 13:22 发表评论

javascript 性能测试系列－－函数调用

金大为 — Tue, 29 May 2007 10:00:00 GMT

一直都认为，javascript的函数调用是一个相对耗时的操作。
开始JSI的优化，这些问题现在必须认真考虑了，测试一把：

一个简单的＋＋操作，直接操作和函数内操作（注，函数参数对原始类型是值传递，所以这不会影响被传入的变量，这里测试里面，两类操作的行为是不一样的）

FF2测试结果（callTime/opTime）：
2871/2582
2919/2675
2734/2704
2953/2516
3732/3346

IE7测试结果：
3140/376
3173/327
3238/247
3265/235
3217/299

通过测试可见，函数调用的消耗基本可以忽略。每次调用时间仅为：
3000/(200*1000*5) ==0.3毫秒，这个时间还包含函数内部的＋＋操作

从示例可见，FF的函数调用消耗基本可以府略，IE虽然相当于十倍＋＋类简单操作，但依然不足以重视。

奇怪的是，第一次碰见ie的运行效率高于ff的情况。

测试代码

金大为 2007-05-29 18:00 发表评论

关于javascript for in 循环效率的疑惑

金大为 — Sun, 27 May 2007 09:18:00 GMT

前几天无意中看到一个网友blog上关于这个循环效率的问题，说要尽量避免使用。
有点害怕，我在JSI中可是用了不少，呵呵。
测试一下，负担终于可以放下来了：

测试对象：
一个对象模拟map，测试for in 循环
两个数组，测试for(;;)循环

连续4次运行时间比。
957/1278；955/1357；1014/1282；968/1392

明显，要实现类似map的功能，还是for in 快点。

上面的数据是ff2上的结果，ie7上也差不多，差距更小一点。

测试代码：

金大为 2007-05-27 17:18 发表评论

几种脚本文本压缩方式压缩比率和解压性能的比较

金大为 — Thu, 24 May 2007 01:28:00 GMT

刚刚修正了一个JSA的bug。

顺便测试了一下文本压缩的性能，和纯packer 压缩，ShrinkSafe＋packer压缩。
压缩大小：
jquery-jsa-s.js（JSA的语法压缩）:29766

jquery.compressed.js（ShrinkSafe语法压缩）:33992

jquery-jsa-st.js（JSA的语法压缩＋文本压缩）:19526

jquery-packer.js（Packer文本压缩）:20977

jquery.compressed-packer.js（ShrinkSafe语法压缩＋Packer文本压缩）:21839

有点奇怪的是，文本压缩和语法压缩是有一定互补性的，但是ShrinkSafe＋Packer比单纯的Packer文本压缩效率还低？？
我想可能是ShrinkSafe做的一些语法补全（可省略的 {、}、;、），jQuery编码的风格导致。

Firefox测试数据（10次压缩时间的毫秒数，连续5回测试数据）

jquery-jsa-st.js:784
jquery-packer.js:1265
jquery.compressed-packer.js:1529

jquery-jsa-st.js:718
jquery-packer.js:922
jquery.compressed-packer.js:766

jquery-jsa-st.js:753
jquery-packer.js:872
jquery.compressed-packer.js:828

jquery-jsa-st.js:1438
jquery-packer.js:1484
jquery.compressed-packer.js:1735

jquery-jsa-st.js:687
jquery-packer.js:1236
jquery.compressed-packer.js:1234

IE5 测试数据（连续三回测试数据）

jquery-jsa-st.js:766
--------------------------------------------------------------------------------
jquery-packer.js:9765
--------------------------------------------------------------------------------
jquery.compressed-packer.js:10547

jquery-jsa-st.js:671
--------------------------------------------------------------------------------
jquery-packer.js:9002
--------------------------------------------------------------------------------
jquery.compressed-packer.js:10265

jquery-jsa-st.js:704
--------------------------------------------------------------------------------
jquery-packer.js:8232
--------------------------------------------------------------------------------
jquery.compressed-packer.js:10314

总结

文本压缩是个比较耗时的操作，像JQuery这样大的类库普遍需要接近100毫秒的解压时间。
如果需要兼容IE5这种老古董，那么最好不要用packer的文本压缩，太耗时。
JSA1 对文本压缩做了些改进，表现还可以。

如果要计较脚本文本压缩后的解压开销，建议使用JSA的语法压缩，配合服务器端的gzip压缩。
不推荐dojo 的ShrinkSafe，原因是它的几个安全问题。

金大为 2007-05-24 09:28 发表评论

BlogJava-jindw的blog-随笔分类-JavaScript

运动曲线研究(缓动效果)

JSA在线压缩程序发布

脚本装载时一个似乎应该有所重视的问题。

JS几处怪癖的语义

[导入]云想衣裳花想容－－JSI组件模型介绍（二）

装饰引擎简介：

装饰器规范简介：

JSI现有装饰器集合简介

[导入]云想衣裳花想容－－JSI组件模型介绍（一）

代码示例：

装饰结果：

[导入] 百花齐放 日月同辉――采用JSI解决不同类库间的冲突

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

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

[导入]脚本安需导入的三种模式的对比

何谓安需装载？

安需装载可分如下三种模式：

使用方法（JSI示例）

示例说明：

参考：

[导入]再谈一下DOMContentLoad事件

JSI2性能测试报告

JSI2Alpha及JSA1beta 发布：

貌似Opera的一个bug

JavaScript模板引擎测试，让我空欢喜一场：（

用正则在Eclipse上对javascript批量缩进。

正则表达式实现JavaScript日期格式化的想法。

JSI API之BrowserInfo、EventUtil讨论

BrowserInfo对象：

不同之处：

不同之处：

javascript 性能测试系列：循环反转的效果

javascript 性能测试系列：正则表达式

javascript 性能测试系列－－函数调用

关于javascript for in 循环效率的疑惑

几种脚本文本压缩方式压缩比率和解压性能的比较

Firefox测试数据（10次压缩时间的毫秒数，连续5回测试数据）

IE5 测试数据（连续三回测试数据）

总结

[导入] 百花齐放日月同辉――采用JSI解决不同类库间的冲突

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

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